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organization of the agh rules:;;^|^^^^;^;^^^^^;;:;v;^:i^^^^^;^;;;:;;v^^^^^^^^^^;\^^^;^^;^^;:^^^;^:^^^^:\I^^ ; ; 

The National Automated Clearing House Association (NAGH 

A Complete Guide to Rules & Regulations Governing t fa 

rule book reflects continued improvements in content and format. In addition to the NACHA Operating Rules 

arid NACHA Operating GuM^ 

Understanding the AGH Network: An ACH Primer, and Quick Find: A Reference Guide to 
the ACH Rules 

How to Implement the 2005 Revisions to the NACHA Operating Rules and NACHA 
Operating Guidelines. 

° Regional Payments Associations/Direct Financial Institution Memb 

° The Federal Reserve Uniform Operating Circular. 

Regulation E, Regulation E Official Staff Interpretation, and the Electronic Fund Transfer 

;::-;-:V(eft^^^ 

e Revised Federal Tax Deposit Payment Information. 

° Title 31 Code of Federal Regulations Part 2 10. 

• 2005 FederalACfr 

The ACH Rules is an annual publication incorporating rule amendments approved by the NACHA Voting 
Membership during the past year. To ensure compliance with current regulations, all network participants 
must obtain the 2005 edition oft^^ 
payments associations listed on the back cover of this book. 

Federal Government ACH Payments 

A revised version of 31 C.F.R. Part 210, the regulation that governs Federal Government ACH payments, 

became effective in May T 999 and adopted the NACHA Operating Rules ^ 

Government payments, with certain exceptions for which special mles have been established as a matt^^ 

Federal law. The most current version of 31 C.F.R. Part 210 is included in this edition of the ACH Rules for 

your reference. You may also obtain a copy from the U.S. Treasury's Financial M 

websiteatwww.fois.treas.gov/ach/orbyc 

(202) 874-6590. The Federal ACH Payments schedule is also included in this publication. 

how to use the book; ■'■■: ::;;:: 

This publication is designed to help you find the answers to your ACH questions quickly and easily. It is 
divided into ten main sections marked by page tabs. The contents arid use of each section are described 
' below:.'- ■/ 

> Understanding the ACH Netw^ 

Network, briefly summarizing the Network's operation, partic 
settlement and posting mechanism, legal framework, and h^ 

Pages in this section are numbered sequentially beginning with the words "ACH Primer." 
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Quick Find: A 

reference to quickly locate specific key areas of ACH processing within both ihe NACHA Operating 
Rules and the NACHA Operating Guidelines. (Note: A complete index is contained at the end of 
both the Rules and Guidelines^) 

Pages in this section are denoted by "Quick Find" 

• How to Implement the 2005 Revisions to the N^ 

a summary of ACH rule changes effective in calendar year 2005 (a convenient ovemew for all AGH 
participants) and may be referred to for information concerning the obligations of ACH participants 
relating to these changes. It also provides information on how to implement these amendments. 
Read this section first to get an overview of recent developments and their impact on your 
operations. 

Pages in Revisions to the 2005 Rules are numbered sequentially beginning with the letters "R." 

The NACHA Operating Rules sectionprowd^ 

effectively meet the needs of users of this book, this edition of the NACHA Operating Rules contains 

language relating to both current rules and rule changes becoming effective later in the year. This 

edition of the Rules contains current rule language, followed immediately by the new rule 

highlighted in italics and brackets. Rule changes within the text are marked by 

left margin, with approval and effective dates for those changes noted at the bottom of the page. 

■'■'.■■■■:■■' Example : ■ 

* [SUBSECTION 2.10.2.2 Verification of Receiver's Identity 

For each WEB entry, the Originator has employed commercially reasonable methods of 
authentication to verify 'the ' identity of the Receiver] 

+ Approved November 9, ^ 

Pages in the NACHA Operating Rules rare numbered sequentially beginning with the letters "OR." 
A complete index is included at the end of this section. 

• The NACHA Operating Guidelm^^ 
guidelines for the mCHA Operating ^ 

responsibilities; procedures forprenotification v retums, notifications of change, reyers 

TM 

the NACHA Operating Guidelines offers detailed chapters on third-party service providers, addenda 
records, OF AC compliance, audit controls and compliance, the National Syste^^ 
and compensation, mapping of ACH formats, Destroyed Check Entries, Automated Enro^ 
cross-border ACH payments, Re-presented Check Entries, Point-of-Purchase Entries, Internet- 
Initiated Entries, Telephone-Initiated Entries, and Accounts Receivable Entries. Guidelines for rule 
changes that become effective later in the year are also included where appropriate. 

Pages in the NACHA Operating Guidelines we m^ 
"GG 1 * A complete index is included at the end of the section. 

• The Regional Payments Associations section ir& 
have their ^o 

for transactions within their regions. Included is contact information for all associations and direct 
financial institution members. Use this section to identify regional processing re^ 
locate an invaluable resource: the ACH payment association in your area. If you have a question or 
problem, call your regional payment association for 
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The pages in this section are denoted by "PAYMENTS ASSOCIATIONS" and are numbered 
sequentially. 

The section containing The Federal Reserve Uniform Operating Circular on Automated Clearing 

House Items states the terms of agreement between the Federal Reserve and financial institutions 
that use the Federal Reserve as an ACH Operator (Uniform Operating Circular) .This inform 
is provided for your reference. 

The pages in this section are denoted by "UOC" and are numbered sequentially. 

Regulation E: Electronic Fund Transfer Act is the Federal regulation governing consumer 
electronic payments. Consult this section for how to handle electronic consumer transactions and 
for safeguards provided to consumer users of this payment method. 

Regulation E pages are indicated by "REG E" and are numbered sequentially. 

Title 31 of the Code of Federal Regulations Part 210 provides ACH users with information on the 
rules governing Federal Government ACH payments. Detailed information may be obtained by 
contacting the Department of the Treasury's Financial Management Service. 

Pages within this section are indicated by "Federal Government Payments" and are numbered 
sequentially. 

* Thz Federal Tax Deposit Payments section contains information important to corporations that are 
required or volunteer to pay federal taxes electronically. Use this section to find details on the 
Electronic Federal Tax Deposit Payment System (EFTPS). 

Federal Tax Deposit Payment pages are numbered sequentially beginning with the letters "FTDP." 

• The 2005 Federal ACH Payments Schedule provides the dates of Federal Government recurring 
benefits and military active duty, reserves, and benefit payments. 

Federal ACH Payments pages are numbered sequentially beginning with the letters "FAPS." 

The Automated Clearing House (ACH) Network is a nationwide electronic payments system used by more 
than 20,000 participating financial institutions, over 4 million corporations, and one hundred thirty-five 
million consumers. 

The concept of a nationwide electronic payments network was championed in the late sixties by a group of 
bankers who recognized the need for an electronic alternative to check payments. In 1 974, after the 
successful development of automated clearing house associations in California, Georgia, New England, and 
the Upper Midwest, the National Automated Clearing House Association (now known as NACHA - The 
Electronic Payments Association) was formed as the regulatory body for the ACH Network. In the thirty-one 
years since that date, the ACH Network has grown to a national payments system processing over ten billion 
payments annually. 

ACH payments offer a wide range of applications to both consumers and corporations/These include, among 
others, direct deposit, pre-authorized bill payment, home banking, point-of-sale and point-of-purchase 
applications, cash concentration and disbursement, corporate trade payments, check truncation, and re- 
presentment of returned NSF checks. These applications are delivered through a fully electronic ACH 
system. To find out more about the nation's largest electronic payments network, contact the payment 
association nearest you. 
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UNDERSTANDING THE ACH NETWORK: AN ACH PRIMER 

This section of the ACH Rules is designed to provide those who are not familiar with the ACH Network or 
this book with a basic understanding of the fundamentals of the ACH Network, briefly summarizing the 
Network's operation, participants, ACH products and services, settlement and posting mechanism, legal 
framework, and history. For complete information on ACH processing, please refer to the NACHA 
Operating Rules and the NACHA Operating Guidelines, which follow. 

A. ACH NETWORK OPERATION 

The ACH Network is a batch processing, store-and-forward system. Transactions received by the financial 
institution during the day are stored and processed later in a batch mode. Rather than sending each payment 
separately, ACH transactions are accumulated and sorted by destination for transmission during a 
predetermined time period. This provides significant economies of scale. It also provides faster processing 
than paper checks, which must be physically handled. Instead of using paper to carry necessary transaction 
information, ACH transactions are transmitted electronically between financial institutions through data 
transmission. 

1. Participants 

Listed below are the participants that are involved in an ACH transaction: 

(a) the originating company or individual (Originator), 

(b) the Originating Depository Financial Institution (ODFI), 

(c) the ACH Operator, 

(d) the Receiving Depository Financial Institution (RDFI), 

(e) the receiving company, employee or customer (Receiver), and 

(f) the Third-Party Service Provider. 

Figure 1 - ACH Participants 
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DEFINITIONS OF THE PARTICIPANTS: 

(a) Originator 

The Originator is the entity that agrees to initiate ACH entries into the payment system according 
to an arrangement with a Receiver. The Originator is usually a company directing a transfer of funds 
to or from a consumer's or another company's account. In the case of a Customer Initiated Entry 
(CIE), the Originator may be an individual initiating funds transfer activity from his or her own 
account. The term "company" is intended to represent the Originator of electronic ACH entries and 
does not imply exclusion of other types of organizations (i.e., Federal, state and local government 
agencies). An Originator may be either a company or a consumer. 

(b) Originating Depository Financial Institution 

The Originating Depository Financial Institution (ODFI) is the institution that receives payment 
instructions from Originators and forwards the entries to the ACH Operator. A depository financial 
institution (DFI) may participate in the ACH system as a Re.ceiying Depository Financial Institution 
(RDFI) without acting as an ODFI; however, if a DFI chooses to originate ACH entries, it must also 
agree to act as an RDFI. 

(c) Automated Clearing House Operator 

An Automated Clearing House (ACH) Operator is the central clearing facility operated by a private 
organization or a Federal Reserve Bank (FRB) on behalf of DFIs, to or from which Participating 
DFIs transmit or receive ACH entries. In some cases, there are two ACH Operators involved in a 
transaction, one operating as the Originating ACH Operator and the other as the Receiving ACH 
Operator. 

(d) Receiving Depository Financial Institution 

The Receiving Depository Financial Institution (RDFI) is the DFI that receives ACH entries from 
the ACH Operator and posts the entries to the accounts of its depositors (Receivers). 

'.(e)' Receiver 

A Receiver is a natural person or an organization which has authorized an Originator to initiate an 
ACH entry to the Receiver's account with the RDFI. A Receiver may be either a company or a 
consumer, depending on the type of transaction. 

ffl Third-Party Service Provider 

In some instances, an Originator, ODFI, or RDFI may choose to use the services of a Third-Party 
Service Provider for all or part of the process of handling ACH entries. A Third-Party Service 
Provider is an entity other than the Originator, ODFI, or RDFI that performs any functions of behalf 
of the Originator, ODFI, or RDFI with respect to the pro 

processing can include, but is not limited to, the creation ofACH files on behalf of an Originator or 
ODFI, or acting as a Sending Point or Receiving Point on behalf of an ODFI or RDFI, respectively . 

As the ACH Network continues to evolve, Third-Party Service Providers have taken on larger and 
more complex roles in the processing of ACH transactions. For a detailed discussion of the specific 
roles and responsibilities of Third-Party Service Providers, refer to the Third-Party Service Provider 
Chapter within ih& NACHA Operating Guidelines . 
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2. ACH Transaction Flow 

In ACH terminology, Originator and Receiver refer to the participants that initiate and receive the ACH 
entries rather than the funds. Unlike a check, which is always a debit instrument, an ACH entry may be 
either a credit or a debit entry. By examining what happens to the Receiver's account, one can distinguish 
the difference between an ACH credit and an ACH debit transaction. If the Receiver's account is debited, 
then the entry is an ACH debit. If the Receiver's account is credited, then the entry is an ACH credit. 
Conversely, the offset to an ACH debit is a credit to the Originator's account and the offset to an ACH credit 
is a debit to the Originator's account. 

(a) ACH Credits 

ACH credit entries occur when an Originator initiates a transfer to move funds into a Receiver's 
account. For example, when a consumer uses an automated bill payment service at a financial 
institution to pay cable access charges each month, the consumer originates the payment through the 
ODFI which then initiates the credit transaction to transfer the money into the cable company's 
account; the cable access company is the Receiver. 

ACH credit transactions involve both consumer and corporate payments with separate rules and 
regulations for each. The most typical consumer ACH application is Direct Deposit of Payroll. 

Figure 2 lists some of the more common credits processed through the ACH Network today: 

Figure 2 - ACH Credits 
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The example in figure 3 illustrates the ACH credit process: 

Figure 3 -ACH Credit Transaction 
In 
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Example: 

As illustrated in Figure 3 , a payroll deposit (PPD) credit flows from an account at a 
company's financial institution to an account at an employee's financial institution. Figure 
3 also illustrates the flow of a corporate trade exchange (CTX) credit from an account at a 
company's financial institution to an account at a vendor's financial institution. Credit 
entries must be posted to a Receiver's account no later than Settlement Date. Consumer 
(PPD) entries that are made available to the RDFI by its ACH Operator by 5:00 p.m. 
(RDFI's local time) on the banking day prior to Settlement Date must be made available by 
opening of business on the Settlement Date. 



(b\ ACH Debits 

In an ACH debit transaction, funds flow in the opposite direction. Funds are collected from a 
Receiver's account and transferred to an Originator's account, even though the Originator initiated 
the entry. For example, the Originator of a preauthorized debit is the company to which the amount 
is owed. Consumers authorize a cable access company to debit their accounts for their monthlybills. 
Once a month the cable access company initiates a debit file through its ODFI to withdraw the 
money from the consumers' accounts. The cable company is the Originator, and the consumers are 
the Receivers. 

Consumer acceptance is highest in the area of pre-authorized transfers involving regular, recurring 
payments, such as mortgage payments, installment loans and insurance premiums. Many 
corporations also use ACH debits to consolidate funds deposited in outlying divisions by operating 
branches or subsidiaries. 
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Figure 4 lists some of the more common debit applications processed through the ACH Network 

today:' > 



Figure 4 -ACH Debits 
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The example in figure 5 illustrates the ACH debit process. 



Figure 5 - ACH Debit Transaction 

Information and Funds Flow 
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Example: 

In f i gure 5 , a preauthorized mortgage payment flows from a consumer's account at a 
financial institution to a mortgage company's account. Figure 5 also illustrates a corporate 
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cash concentration flow from a company's local or regional financial institution account to 
a company's regional or national financial institution account. Debit entries must not be 
posted to a Receiver's account prior to the settlement date. 



A typical transaction as it flows through the ACH Network might follow the path described below: 

The Originating Depository Financial Institution (ODFI) and the originating company determine, 
by agreement, how the information must be delivered to the ODFI. Ideally, the Originator would 
format the data in accordance with the requirements of the NACHA Operating Rules md transmit 
the information to the ODFI, but some financial institutions may take unformatted data as a service 
to their client companies. The ODFI establishes processing schedules and cutoff times with its 
Originators so that entries may be processed and transmitted in suffi cient time for settlement to occur 
on the dates desired by its Originators. 

The company delivers the file to its ODFI. The timing of delivery must conform to appropriate 
schedules in order for the payment to settle on the intended date. 

■'• The ODFI generally removes "on-us" entries and transmits the remaining entries to the originating 

ACHOperatorby the ACH Operator's processing deadline. An "on-us" transaction is one in which 
the Receiver and the Originator both have accounts at the same financial institution. Therefore, the 
transaction need not be sent through the 
financial institution and posted to the appropriate account. 

The ACH Operator sorts the entries by RDFI routing number and transmits the payment information 
to the appropriate RDFI(s) for posting. 

On Settlement Date, all parties to the transaction effect the appropriate settlement of funds. 

: B CONSUMER VS. CORPORATE PAYMENTS : ; : : 

ACH transactions are typically categorized as either consumer payments or corporate payments, depending 
on the relationship of the parties involved in the. transaction and the type of Receiver account. In addition, 
payments are distinguished as Federal Government payments (representing automated disbursements 
originating from the United States Government, such as Social Security benefits, military and civilian 
payrolls, retirement benefits, tax refunds, and disbursements for state and federal revenue sharing programs) 
or commercial payments (initiated by both individual consumers and corporations) . 

Consumer payments currently made via the ACH Network include credit applications such as payroll, 
retirement, dividend, interest, and annuity payments, in addition to educational benefit reimbursements, 
payments and advances, and many others. Consumer ACH debit applications include, among others, the 
collection of insurance premiums, mortgage and rent payments, utility payments, installment payments, a 
variety of membership dues, and other recurring obligations. The ACH Network is also widely used to settle 
consumer transactions made at automated teller machines and point-of-sale terminals. 

Corporate ACH applications include cash concentration and disbursement, corporate trade payments, state 
and Federal tax payments and financial electronic data interchange (EDI). Cash concentration and 
disbursement allows companies to achieve efficiencies in cash management through timely mtra-company 
transfer of funds. Corporate trade payments enable corporations to exchange both data and funds with 
trading partners, facilitating an automated process of updating their accounts receivable and accounts payable 
■ ; systems.'/.; 
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C. PAYMENT APPLICATIONS 

The ACH Network supports a variety of payment applications. An Originator initiating entries into the 
system will code the entries in such a manner as to indicate the type of payment, such as a debit or credit, 
and whether an entry is consumer or corporate in nature (i.e.; the funds transfer affects either a consumer 
account or a corporate account at the RDFI). Each ACH application is identified and recognized by a 
specific three-digit code, known as a Standard Entry Class Code (SEC Code), which appears m the ACH 
record format. The SEC Code identifies the specific be used to carry the 

payment and payment-related information relevant to the application. Following is a list of Standard Entry 
Class Codes and the different products each code supports. 

1. Consumer Applications 

ARC - Accounts Receivable Entry 

This Standard Entry Class Code enables Originators to convert to a Single Entry ACH debit a 
consumer check received via the U.S. mail or at a dropbox location for the payment of goods or 
services. The consumer' s source document (i.e., the check) is used to collect the consumer's routing 
number, account number, check serial number, and dollar amount for the transaction. 

CIE - Customer Initiated Entry 

v Customer Initiated Entries are limited to credit applications where the consumer 

of funds to a company for payment of funds owed to that company, typically through some type of 
home banking product or bill payment service provider. 

MTE - Machine Transfer Entry 

The ACH Network supports the clearing of transactions from Automated Teller Machines, i.e., 
Machine Transfer Entries (MTE). 

PBR- Consumer Cross-Border Payment 

This Standard Entry Class Code is used for the transmission of consumer cross-border ACH credit 
and debit entries. This SEC Code allows cross-border payments to be readily identified so that 
financial institutions may apply special handling requirement 

The PBR format accommodates detailed information unique to cross-border payments (e.g., foreign 
exchange conversion, origination and destination currency, country codes, etc.). 

POP - Point-of-Purchase Entry 

This ACH debit application is used by Originators as a method of payment for the in-person 
purchase of goods or services by consumers. These Single Entry debit entries are initiated by the 
Originator based on a written authorization and account information drawn from the source 
document (a check) obtained from the consumer at the point-of-purchase . The source document, 
which is voided by the merchant and returned to the consumer at the point-of^purchase, is used to 
collect the consumer's routing number, account number, and check serial number that will be used 
to generate the debit entry to the consumer's account. 

PPD -Prearranged Payment and Deposit Entry 

Direct Deposit 

Direct deposit is a credit application that transfers funds into a consumer's account at the Receiving 
Depository Financial Institution. The funds being deposited can represent a variety of products, such 
as payroll, interest, pension, dividends, etc. 
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Preauthonzed Bill Payment 

Preauthorized payment is a debit application. Companies with billing operations may participate in 
the ACH through the electronic transfer (direct debit) of bill payment entries. Through standing 
authorizations, the consumer grants the company authority to initiate periodic charges to his or her 
account as bills become due. This concept has met with appreciable success in situations where the 
recurring bills are regular and do not vary in amount --insurance premiums, mortgage payments, and 
installment loan payments being the most prominent examples. Standing authorizations have also 
been successful for bills where the amount does vary, such as utility payments. 

POS/SHR- Point of Sale Entry/Shared Network Transaction 

These two Standard Entry Class Codes represent point of sale debit applications in either a shared 
(SHR) or non-shared (POS) environment. These transactions are most often initiated by the 
consumer via a plastic access card. 

RCK- Re-presented Check Entry 

A Re-presented Check Entry is a Single Entry ACH debit application used by Originators to re- 
present a check that has been processed through the check collection system and returned because 
of insufficient or uncollected funds. This method of collection 

the checkcollection process, provides Originators with the potential for improvements to processing 
efficiency (such as control over timing of the initiation of the debit entry) and decreased costs . 

TEL 'Telephone-Initiated Entry 

This Standard Entry Class Code is used for the origination of a Single Entry debit transaction to a 
consumer's account pursuant to an oral authorization obtained from the consumer via the telephone. 
This type of transaction may only .be originated when there is either (1) an existing relationship 
between the Originator and the Receiver, or (2) no existing relationship between the Originator and 
the Receiver, but the Receiver has initiated the telephone call. This SEC Code facilitates access to 
the ACH Network by providing an alternative authorization method, oral authorization via the 
telephone, for certain types of consumer debit entries. 

WEB - Internet-Initiated Entry 

This Standard Entry Class Code is used for the origination of debit entries (either recurring or Single 
Entry) to a consumer's account pursuant to an authorization that is obtained from the Receiver via 
the Internet. This SEC Code helps to address unique risk issues inherent to the Internet payment 
environment through requirements for added security procedures and obligations. 

2. Corporate Applications 

CBR -Corporate Cross-Border Payment 

This Standard Entry Class Code is used for the transmission of corporate cross-border ACH credit 
and debit entries. This SEC Code allows cross-border payments to be readily identified so that 
financial institutions may apply special handling requirements for cross-border payments, as desired. 
The CBR format accommodates detailed information unique to cross-border payments (e.g., foreign 
exchange conversion, origination and destination currency, country codes, etc.). 

CCD-Cash Concentration or Disbursement 

This application, Cash Concentration or Disbursement, can be either a credit or debit application 
where funds are either distributed or consolidated between corporate entities. This application can 
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serve as a stand-alone funds transfer, or it can support a limited amount of payment related data with 
the funds transfer. 

CTX - Corporate Trade Exchange 

The Corporate Trade Exchange application supports the transfer of funds (debit or credit) within a 
trading partner relationship in which a full ANSI ASC X 1 2 message or payment related 
UN/EDIFACT information is sent with the funds transfer. The ANSI ASC XI 2 message or payment 
related UN/EDIF ACT information is placed m multiple addenda records. 

3. Other Applications 

ACK/ATX - Acknowledgment Entries 

These optional Standard Entry Class Codes are available for use by the RDFI to acknowledge the 
receipt of ACH credit payments originated using the CCD or CTX formats. These acknowledgments 
indicate to the Originator that the payment was received and that the RDFI will attempt to post the 
payment to the Receiver's account. Acknowledgment entries initiated in response to a CCD credit 
entry utilize the ACK format. Acknowledgments initiated in response to a CTX credit entry utilize 
the ATX format. 

ADV - Automated Accounting Advice 

This Standard Entry Class Code represents an optional service to be provided by ACH Operators that 
identifies automated accounting advices of ACH accounting information in machine readable format 
to facilitate the automation of accounting information for Participating DFIs. 

COR - Automated 'Notification of Change ot Refused Notification of Change 

This Standard Entry Class Code is used by an RDFI or ODFI when originating a Notification of 
Change or Refused Notification ofChange in automated format. It is also used by the ACH Operator 
that converts paper Notifications of Change to automated format 

DNE - Death Notification Entry 

This application is utilized by a Federal Government agency (e.g., Social Security Administration) 
to notify a depository financial institution that the recipient of a government benefit payment has 
died. 

ENR - Automated Enrollment Entry 

This optional SEC Code allows a depository financial institution to transmit ACH enrollment 
information to Federal Government Agencies via the ACH Network for future credit and debit 
applications on behalf of both consumers and companies. 

TRC/TRX- Truncated Entries 

This Standard Entry Class Code is used to identify batches of truncated checks. For more 
information on check truncation, please see the National Association for Check Safekeeping 
Guidelines available from NACHA;'-.::'::' .'.>.■ ■■■.;■'■;.;: 

XCK - Destroyed Check Entry 

This application can be utilized by a collecting institution for the collection of certain checks when 
those checks have been destroyed. 
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P..- - ADVANTAGES TO PARTICIPANT 

Each participant in the ACH Network benefits through improvements in service and reductions in operating 
costs. The following specific advantages have been identified for each participant: 

Advantages to Consumers 

■'•. Direct deposit offers the following benefits to the recipient: 
■ ■'.- Elimination of time and cost involved in depositing checks. 

- Consistent availability of funds on a timely basis, even during vacation, illness, or business trips. 
■.'-■ Elimination of the possibility of lost or stolen checks. 

■ •; Debit applications provide the following benefits to the consumer: 

- Convenience of not having to write checks. 

'■'-■ Elimination of postage expense and the risk of late payments. 

- Avoidance of late or interest charges through prompt, timely payments. 
V Establishment of exce^ 

Advantages to Companies (Originators or Receivers) 
'■• Reduction of administration and operating expenses. 

• Elimination of time lost by employees who deposit checks during working hours. 
-.'• Reduction of clerical cost for account reconciliation. 

■ • Elimination of stop payment charges and check reissue costs. 

• Reduced remittance processing costs (paper handling) resulting from the absence of the check. 
9 Accelerated availability of funds. 

■■.• Better cash management forecasting. 
'.■• Improved business relationships. 
■• Certainty of delivery. 

• Possible reduction of bank service charges. 

Advantages to the Originating Depository Financial Institution 
V Reduction of costs through increased automated processing. 

• New opportunities for increased business through expanded services. 

■■>';■ Enhanced public recognition through provision of effective, efficient, and innovative payment services. 
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Advantages to the Receiving Depository Financial Institution 

V Reduction of costs through automated processing of electronic entries and elimination of handling 
individual items. 

V Alleviation of teller-lme congestion during peak periods (particularly on payday). 

• Ability to offer improved services to both consumer and corporate account holders. 
■ • ■; Enhanced public recognition through provision of effective, efficient, and innovative payment services. 

E. SETTLEMENT AND POSTING ... 

Settlement is the actual transfer of the value of funds between financial institutions to complete the payment 
instruction of an ACH entry. 

The Federal Reserve provides settlement services for ACH entries processed by the Federal Reserve and for 
private sector ACH Operators that process ACH entries. The Federal Reserve ACH Operator calculates the 
net credit and debit positions of financial institutions and applies those credits or debits to the reserve 
accounts of the financial institutions (or their correspondent banks) that are maintained on the books of the 
Federal Reserve. 

The following are the three main participants (ODFI, ACH Operator, RDFI) and their responsibilities 
concerning settlement and posting. 

/l^ODFT;.^ 

Settlement with the ODFI for entries originated usually occurs using the same procedures used for settlement 
of entries received. If the scheduled settlement date of a credit entiy is not a banking day for the ODFI, but 
the applicable Federal Reserve office is open on that date, settlement shall occur on the scheduled Settlement 
Date. 

Specific procedures and timing of settlement between the ODFI and the Originator are solely at the discretion 
of the ODFI and the Originator and, therefore, governed by agreement between them. It is the ODFI's 
responsibility to monitor the credit- worthiness of its corporate customers to ensure that the ODFI's risk in 

originating ACH payments is managed efficiently. 

2. ACH Operator 

ACH Operators calculate settlement totals owed to and by Participating DFIs based on the effective entry 
dates and processing dates contained within batches of transactions. ACH Operators provide information 
to participants on the dollar amounts that will be settled for each institution on each Settlement Date. ACH 
entries processed by the Federal Reserve ACH Operator are settled against the Participating DFTs settlement 
account held at the Federal Reserve. Settlement for transactions processed by private sector ACH Operators 
is determined by an arrangement with the Federal Reserve. 

I; RDFI . .V.; : ■ , ; : '''v.\: ■.■.■. : ;. : v '::.^ 

■■■■■.'■■■ (a) Posting :-.y. 

The RDFI is responsible for posting entries and for providing funds availability, both of which are 
determined by the Settlement Date in the Company Batch Header Record. 

> ACH debits will be delivered to an RDFI no earlier than one banking day prior to the Settlement Date. 
NACHA Operating Rules state 
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If an RDFI is closed for business on the scheduled settlement date of a debit entry, but the Receiving 
ACH Operator is open, the RDFI will be debited on the scheduled Settlement Date unless it has 
advised the ACH Operator to delay settlement to the next business day of the RDFI. If the AGH 
Operator agrees to delay settlement, the RDFI must pay for any costs of float resulting from the 
deferral of settlement. 

• ACH credits will be delivered to an RDFI no earlier than two banking days prior to the settlement 
date. It is recommended that credits be posted on the settlement date; credit entries may, however, 
be posted prior to the settlement date if the RDFI cannot warehouse the entry .NACHA Operating 
Rules require that credit entries must be available for withdrawal or cash withdrawal by the custome 
no later than the settlement date of the entry . Further, according to NACHA Operating Rules, each 
PPD credit entry that is made available to an RDFI by its ACH Operator by 5:00 p.m. (RDFI's local 
time) on the banking day prior to the settlement date must be made available to the Receiver for 
withdrawal or cash withdrawal at the opening of busing 

of the preceding sentence, opening of business is defined as the later of 9:00 a.m. (RDFI's local time) 
or the time the RDFI's teller facilities (including ATMs) are available for customer account 
withdrawals. 

(b) Settlement .;.-"/■ ;-: : ;;"." : --'-; ; >■;."■" :■ : / ■:'■."■;/"■■.'■■; ;:V:/.-. 

Settlement between the Originator and the ODFI is governed by agreement. Settlement between the 
RDFI and the Receiver is determined by 'the NACHA Operating Rules, Federal Reserve availability 
schedules, and agreement. 

When an ACH file is processed by the receiving ACH Operator, the ACH Operator will read the 
Effective Entry Date in the Company/Batch Header Record and settle according to that date. If the 
file has been deli vered to the ACH Operator so that the ACH Operator is able to settle on the Effective 
Entry Date, it will insert the corresponding Julian Date in the Settlement Date field. If the ACH 
Operator cannot settle on the Effective Entry Date dueto a stale date, weekend; or holiday, the ACH 
Operator will insert the Julian Date of the next business day into the Settlement Date field refl^^ 
that settlement will occur on that date. 

• Settlement information is produced by the ACH Operator as AGH entries are processed. This 
information is accumulated based on the type of entry (debit or credit) by settlement date. These 
settlement totals are reported to the RDFI or its settlement member correspondent. 

• The ACH Operator may provide ACH settlement information in a machine-readable format to 
facilitate the automation of settlement accounting for correspondent RDFIs. 

'■'• Settlement totals should be balanced daily against totals posted to the RDFI's customer accounts and 
against any rej ects that may occur. Rej ects and other differences must be resolved immediately. 

• ACH settlement procedures are the same for consumer and corporate transactions. In view of the 
large-dollar entries that flow through the ACH Network for corporate customers, RDFIs should have 
internal procedures in place to monitor large-dollar settlement totals. 

F LEGAL FRAMEWORK 

The ACH process operates from beginning to end through a series of legal agreements. Before any 

transaction is initiated, the Originator and ODFI execute an agreement to use the ACH Network to originate 

payments. Among other things, the agreement shouldbind the originating company to the ^ 

Rules, define the parameters of the relationship between the two parties, identify processing requirements 

for the specific application(s), and establish liability and accountability for procedures related to certain 

applicat^ 
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intraregional ACH transactions unless a regional ACH association has implemented a local rule to supersede 
a provision of the NACHA Operating Rules. 

While the NACHA Operating Rules is the primary document addressing the rules and regulations for the 

commercial ACH Network, Federal Government ACH payments are controlled by the provisions of Title 3 1 

Code of Federal Regulations Part 210 (31 C.F.R. Part 210). The Financial Management Service (FMS) of 

the U.S. Department of the Treasuty is the agency responsible for establi 

policy. In 1999, 31 C.F.R. Part 210 was revised by FMS to adopt the provisions of the A^ 

Rules as the regulations governing the transmission and receipt of Federal Government ACH entries, with 

certain exemptions to address matters of Federal law. FMS also pub 

manual for Federal Government ACH payments. 

Other laws that have a direct bearing on ACH operations are the Uniform Commercial Code Article 4, which 
governs check transactions, and Article 4A, and the Electronic Funds Transfer Act as implemented by 
Regulation E. Certain other activities related to ACH payments are affected by The Right to Financial 
Privacy Act, Regulation D regarding reserve requirements, Regulation CC regarding funds availability, and 
other regulatory agency directi ves . Agreements are also required between RDFIs and the ACH Operators for 
ACH Operator services. Relationships between the consumer as Receiver and the RDFI are generally 
governed by Regulation E and the NACHA Operating Rules. In some cases, agreements exist between the 
RDFI and the Receiver, particularly if the Receiver is a corporate or government 

G. HISTORY OF THE ACH NETWORK 

The ACH Network is a processing and delivery system that provides for the distribution and settlement of 
electronic credits and debits among financial institutions. The ACH Network was developed in response to 
the astronomical growth of check payments and the many technological advances in the mid-twentieth 
century and functions as an efficient, electronic alternative to paper checks. Through a nationwide 
telecommunications network, each ACH Operator is able to communicate with other ACH Operators to 
exchange entries quickly and efficiently, regardless of geographic distances involved. The ACH Network 
offers an assortment of technical formats that can be used for a variety of payment applications, products and 
services. The ACH Network is governed by operating rules and guidelines, which are developed by the 
actual users of the system, and is administered through a series of agreements among financial institutions, 
customers, trading partners, and A 

The ACH movement began in the early 1970s when a group of California bankers formed the Special 
Committee on Paperless Entries (SCOPE) . In direct response to the rapid growth in check volume, the 
Committee was chartered to explore the technical, operational, an 
automated payments system. 

SCOPE laid the groundwork for the first Automated Clearing House (ACH) association, which began 
operation in 1972. The establishment of this ACH association led to the formation of similar groups in o&^^ 
parts of the country. Agreements were made between the emerging regional ACH associations and the 
regional Federal Reserve Banks to provide facilities, equipment, and staff to operate regional ACH networks. 
Two notable exceptions to this type of arrangement occurred in New York and Chicago, where private 
clearing houses were formed to handle ACH transactions. 

In 1 974, the National Automated Clearing House Association (NACHA) was formed to coordinate the ACH 
movement nationwide. Through the joint efforts of NACHA and the Federal Reserve System, local ACHs 
were linked electronically on a nationwide basis in 1 978. The main benefits associated with the use of the 
ACH Network are cost reduction and improved productivity over paper check transactions. 

In an effort to improve the payments system, Congress enacted the Monetary Control Act in 1980. As a 
result of that Act, private sector ACH Operators were encouraged to compete with the Federal Reserve, 
which could no longer offer its services free of charge and was required to recover its operating costs. A 
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private sector adjustment factor (i.e.; profit 'margin) is included in Federal Reserve processing so that the 
Federal Reserve Bank charges as though it were operating on a '■■ for profit" basis. 

NAGHA and the Regional Payments Associations 

NACHA oversees America's largest electronic payments network NA^ 

and maintain the NACHA Operating Rides] to promote ^ to provide educational 

services to its members and other ACH participants. NAGHA's member payment associations serve over 
12,000 financial institutions across the United States; which in turn provide services to over 4 million 
corporations and one hundred thirty-five million consumers, with a transaction volume of ten billion 
payments and a dollar value $27.4 trillion in 2003. 

Regional payment associations provide management, education, assistance, and services to link all types of 
financial institutions (commercial banks, saving banks, and credit unions) across the United States. Several 
of these associations also develop and implement local ACH rules that apply specifically to their own 
member financial institutions. The regional payment associations offer a wide variety of educational sessions 
ranging from origination and receipt operations to audit and control. 

H ACH TERMINOLOGY 

This section is intended to provide users of this book with an overview of basic ACH terminology. ACH 
terms, as defined specifically for purposes of the NACHA Operating ^7?w/es, may be found within Article 
Thirteen of the NACHA Operating Rules . 

■ACH:Operator^V/ : ^v^-;> 

means (1) a Federal Reserve Bank that performs all of the following, or (2) an entity that executes an annual 
agreement with the National Associ a tion in which the entity agrees to comply with or perform all of the 
following: 

(a) adhere to these rules (except to the extent inconsistent with the policies or practices of the Federal 
Reserve Banks) and other applicable laws, regulations, and policies; 

(b) execute agreements with a minimum of twenty independent (i.e., not owned by the same holding 
company) Participating DFIs that bind such entities to the ACH Operator's rules and to these rules 
(except that a Federal Reserve Bank shall not be required to bind a Participating DPI to any provision 
of such rules of the National Association that is not incorporated by the Uniform Operating Circular 
of the Federal Reserve Banks); 

(c) (i) provide clearing, delivery, and settlement services for ACH entries, as defined by these rules, 
between Participating DFIs that have selected that ACH Operator to perform ACH services (intra- 
ACH Operator services), and (ii) exchange transactions with other ACH Operators (inter-ACH 
Operator exchange); 

(d) process and edit files based on the requirements of these rules; 

(e) evaluate the credit worthiness of and apply risk control measures to their Participating DFIs; 

(f) adhere to the Federal Reserve's Policy Statement on Privately Operated Multilateral Settlement 
Systems (as applicable); and 

(g) adhere to any National ACH Operator Performance Standards of the National Association . 

Addenda Record 

An ACH record type that carries the supplemental data needed to completely identify an account holder(s) 
or provide information concerning a payment to the RDFI and the Receiver. 

Authorization 

A written agreement with the originating company signed or similarly authenticated by an employee or 
customer to allow payments processed through the ACH Network to be deposited in or withdrawn from his 
or her account at a financial institution. (For specific applications, written authorization for debits to 
consumer accounts is not required. Refer to the NACHA Operating Rules for detail 
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agreement that defines the terms, conditions and legal relationship between trading partners. For ACH credit 
entries, authorization may also be by verbal or other non- written means . 

Automated Clearing House (ACH) Network 

A funds transfer system, governed byiheNACHA Operating Rules, that provides for the interbank clearing 
of electronic entries for participating financial institutions. 

Banking. Day 

Any day on which a participating depository financial institution is open to the public during any part of the 
day for carrying on substantially all its banking functions.^^^^^^^^^^^^^^-0^^^^^^^^^^^^^:^^^^^^^^^^;;. 

.■ Batch ■ 
A group of records or documents considered as a single unit for the purpose of data processing. 

Consumer Account 

A deposit account held by a financial institution and established by a natural person primarily for personal, 
family, or household use and not for commercial purposes. 

Corporate-to-Corporate Payments 

Any of the class of automated payment formats developed for the ACH Network that allow concurrent 

exchange of funds and remittance information between trading partners. 

'. Credit. Entry 

An entry to the record of an account to represent the transfer or placement of funds into the account 

Data Transmission 

The electronic exchange of information between two data processing points. 

: Debit Entry; . 
An entry to the record of an account to represent the transfer or removal of funds from the account. 

Direct Debit .'■■:■'. 

A method of collection used in the ACH for certain claims, generally those that are repeated over a period 
ot time, under which the debtor gives his or her financial institution authorization to debit his or her account 
upon the receipt of an entry issued by a creditor. 

■ Direct Deposit 

An ACH service that provides for the electronic transfer of funds directly into the account of a payee usually 
an employee receiving pay or a Social Security beneficiary receiving retirement benefits. 

. Direct Payment 

A method of collation used m the ACH Network fo 

a period of time, for which the debtor gives the Originator an authorization to debit his or her account. 

EDI Payment 

The computer-to-computer transmission of a payment and related information in a standard format. 

Effective Entry Date 

/the date the originating company expects payment to take place. The ACH Operator reads the effective 
entry date to determine the settlement date. 

Electronic Funds Transfer (EFT) 

A generic term used to describe any ACH or wire transfer. 
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Entry' ; ■■ :; " ' ■' ; ' u ■' ' r-u 

An electronic item representing the transfer of funds m. the ACH. 

One or more consecutive character positions withm an AGH entry mapped to contain specific information. 
For credit, debit or ATM cards, a defined area within an information track of the magnetic stripe of fixed or 
variable length. 

A ffoup of ACH batches initiated into the ACH Network or sorted for delivery to ACH receiving point(s). 
A file must be transmitted electronically via data transmission between the sending point and the receiving 
point. A file maybe delivered to an end-point via direct data transmission, magnetic tape, or floppy diskette. 
A file may contain one or more batches of entries. 

Financial EDI ■, .>'■' • V 

Electronic data interchange for financial transactions/applications between companies, and financial 
institutions, including payment and remittance advice, account analysis, and balance reporting. 

Funds Availability ,11^1. v 

The time at which the funds resulting from a funds transfer are made available to the customer. 

A publicahon assembled by the U.S. Department of the Treasury that specifies the procedures to be used in 
Automated Clearing House transactions originated on behalf of the Umted States Federal Government. 

"Lr^refe^^ such aS Prenotifications. 

MICRline , ■.■', :'■■■■ '-.'■' ■; ,^ 

The magnetic ink character recognition inscription at the bottom ot a paper checic. 

National Automated Clearing House Association 

ThenSonal association that establishes the standards, mles and procedures that enaW^ 
institutions to exchange payments on a national basis. 

accepted and warranted payment format standards for payments delivered through the ACH. 

£Sffis^%?S^otify;ite QDH thatpreviously valid information for a receiver has become 
outdated or that information contained in a prenotification is erroneous. The standard entry class code is 

. ■ COR ';■'■ 

: On-Us Entries :; ;; ■ V : - 

Entries within an ACH file destined for accounts held at the ODM. 

Orieinatine Depository Financial Institution (ODFI) ,, + + u ':** 

A particlpanng financial institution that initiates ACH entries atthe reques^ of and^agreement W1 th its 
customers. ODFIs must abide by the provisions of the NACHA Operating Rules and Guidelines. 
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Posting : .■ 

The process of recording debits and credits to individual account balances. 

Prenotification 

A non-dollar entry that may be sent through the ACH Network by an Originator to alert an RDFI that a live- 
dollar transaction will be forthcoming and that verification of the Receiver's account number is required. 

Receiver.-' . : . ■ \ .■;'.'■■■.■ ■ 

An individual, corporation or other entity who has authorized an originator to initiate a credit or debit entry 

to an account held at an RDFI. 

Receiving Depository Financial Institution (RDFI) 

Any financial institution qualified to receive ACH entries that agrees to abide by the -NACHA Operating 
Rules and Guidelines. 



Receiving Point 

/V site where entries are received from an ACH Operator for processing. It may be the RDFI, its data center 
or a data processing service bureau authorized to receive entries on behalf of a RDFI. 

Regulation E 

A regulation promulgated by the Federal Reserve Board of Governors in order to ensure consumers of a 

minimum level of protection in disputes arising from electronic funds transfers. 

..Returns' ; : .- 

Any ACH entry that has been returned to the ODFI by the RDFI or by the ACH Operator because it cannot 
be processed. The reason for each return is included with the return in the form of a "return reason code." 
(See the NACHA Operating Rules and Gw/^e/me^ for complete return reason code listing.) 

Reversals/'. 

Any ACH entries or files sent within required deadlines to "correct" or reverse previously originated 
erroneous entries or files. 

Routing Number 

A nine-digit number (eight digits and a check digit) that identifies a specific financial institution. Also 
referred to as the ABA number. Numbers are assigned by the Thomson Financial Publishing and are listed 
in its publication entitled Key to Routing Numbers. 

Sending Point 

A processing site from which entries are transmitted to the ACH Operator. It may be the ODFI on its own 
behalf or a financial institution or private data processing service bureau on behalf of the ODFI. 

Settlement 

A transfer of funds between two parties in cash, or on the books of a mutual depository institution, to 
complete one or more prior transactions, made subj ect to final accounting. Settlement for the ACH Network 
usually occurs through the Federal Reserve, 

Settlement Date 

The date on which an exchange of funds with respect to an entry is reflected on the books of the Federal 
Reserve Bank(s). 

Standard Entry Class Codes 

Three character code within an ACH company/batch header record that identifies payment types within an 
ACH batch (e.g., CCD, CTX, etc.). 
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Transaction. Code. . 

The two digit code in the ACH record that determines whether an entry is a debit or a credit to a DDA 
account, savings account, or general ledger account, or whether an entry is a credit to a loan account. 
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QUICK FIND: A REFERENCE GUIDE TO THE ACH RULES 

This section is intended to facilitate the location of specific areas within the NACHA Operating Rules and 

NACHA Operating Guidelines as they relate to a particular ACH topic or function. These references are not 

a substitute for an understanding of the rules, nor do the explanations of each topic substitute for the legal 

language or definitions contained within the NA CHA Operating Rules. VW 

the accuracy of this section, completeness of reference cannot be guaranteed. Some listings are brief because 

an entire article or section is referenced, while others are 

places within the rules. 




. ACKNOWLEDGMENT ENTW 

Optional entries transmitted by the RDFI to provide notice to the ODFI that a corporate credit entry initiated 
using the CCD or CTX format has been received by the RDFI. 



Rules 

Article Six, section 6.5 

Appendix VII 



Acknowledgment Entries 
Acknowledgment Entries 



Guidelines 

Section II, Chapter I (Originators), subsection C (Acknowledgment Entries) 
Section II, Chapter II (ODFIs), subsection D (Acknowledgment Entries) 
Section II, Chapter IV (RDFIs), subsection C-3 (Processing of ACH Files) 
Section III, Chapter V (Acknowledgment Entries) 

ACCOUNTS RECEIVABLE ENTRIES 

Single-Entry debits initiated by an Originator for the conversion of consumer checks provided to the 
Originator via the U.S. mail or placed in a dropbox for the payment of goods or services. The consumer's 
source document (i.e., the check) is used to collect the consumer's routing number, account number, check 
serial number, and dollar amount for the transaction. 



Rules 

Article Two, subsection 2.1 .4 
Article Two, section 2.9 
Article Three, section 3.7 
Article Four, subsection 4.1.1 
Article Eight, section 8.4 
Article Eight, subsection 8.6.4 
Article Eight, subsection 8.6.5.1 

Article Eight, subsection 8.7.4 
Article Fourteen, subsection 14.1.6 
Appendix Two, subsection 2.1.5 
Appendix Two, section 2.2 
Appendix Two, section 2.3 



Notification for Accounts Receivable Entries 

Accounts Receivable Entries 

Obligations of Originators of ARC Entries 

Right to Information Regarding Entries 

Stop Payment Affecting Consumer Accounts 

Receiver's Right to Recredit for ARC Entries 

Receiver's Written Statement Under Penalty of Perjury for ARC 

Entries 

RDFTs Right to Adjustment for ARC Entries 
ARCEntry 

Sequence of Records for ARC Entries 
Code Values 

Glossary of File Format Data Elements 



Guidelines 

Section TV, Chapter XIII (Accounts Receivable Entries) 
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ADJUSTMENT " . . . 

Return entry transmitted by an RDFI in the amount of an unauthorized consumer debit entry. 

Rules 

Article Eight, section 8.7 Adjustment Entries 

AGREEMENT BETWEEN ORIGINATOR AND ODFI 

Agreement required by the NA CHA Operating Rules between the Originator and the ODFI. Authorizes the 
ODFI to transmit entries on behalf of the Originator, binds the Originator to the NACHA Operating Rules, 
defines the processing requirements, responsibilities, and liabilities of both parties with respect to the 
origination of ACH entries. 

Rules 

Article Two, subsection 2.1.1 Originator Authorization and Agreement 

Guidelines 

Section II, Chapter I (Originators), subsection B-2 (Relationship with ODFI) 

Section II, Chapter II (ODFIs), subsection C-3 (Agreements/Relationship with Originator) 

APPLICATION OF RULES: 7. -..':-■ ' -^ ■' : - ■' ■ 7 ■ : ' -.. A ^ u 

Statement defining that the NACHA Operating Rules apply to all entries and entry data transmitted through 

one or more ACH Operators. 

Rules 

Article One, subsection 1.1 Application of Rules 

ARBITRATION .'.''. ■'■'.-^'" ",- ■ 7" ■ ■ .7:--x"7 ."-^"-^ ■ "=V7": ■ -.-"7- ■ 

Provides for the settlement of disputes arising under the NACHA Operating Rules between Participating 

DFIs. 

TELuks - 7 
Article One, subsection 1 .2.3 Arbitration 

Appendix Ten A^^ 

Guidelines 

Section TV, Chapter VI (Arbitration and Compensation) 

\ audit and compliance; ;. 7.;. ;;;.;;; I 

Each Participating DFI and third-party service provider performing a function of ACH processing on behalt 
of a Participating DFI must conduct an annual audit of its compliance with the NACHA Operating Rules. 

Rules .' 

Article One, section 1 2 Compliance with Rules 

Article One, subsection 1 .2.1 Audits 

Appendix Eight Rule Compliance Audit Requirements 



Guidelines 

Section II, Chapter II (ODFIs), subsection N (Audit Requirements) 

Section II, Chapter IV (RDFIs), subsection G (Audit Requirements) 



QUICK FIND 2 



2005ACHRULES : . ■. /..■ .;. V; ': ■/^: ■•.';;::;.; : .; Z;/ ^•. : V;/ ;V ;,V ; ;..:.•.; QUICK FIND 

Section IV, Chapter IV (Audit Controls and Compliance) 
Related Topics: Rules Enforcement 

AUTHORIZATION 

With limited exceptions, all ACH entries must be authorized by both the Originator and the Receiver. The 
Receiver must authorize the Originator to initiate entries to the Receiver's account. The Originator must 
authorize the ODFI to initiate entries on its behalf 




: Rules 

Article Two, subsection 2.1 .1 Originator Authorization and Agreement 

Article Two, subsection 2.1.2 Receiver Authorization and Agreement 

Article Two, subsection 2. 1 .3 Exception to Authorization Requirement 

Article Two, subsection 2.1.4 Notification for Accounts Receivable Entries 

Article Two, subsection 2.1.6 Authorization for Telephone-Initiated Entries 

Article Two, section 2.2 Warranties and Liabilities of ODFI (see 2.2.1.1, 2.2.1.4, 2.2.1.5) 

Article Three, section 3. 5 Consumer Accounts -Copy of Debit Authorization 

Article Three, section 3 . 12 Record of Authorization 

Article Four, subsection 4. 1.1 Right to Information Regarding Entries 

Guidelines 

Section II, Chapter I (Originators), subsection B (Legal Responsibilities - Agreements and Authorizations) 

Section II, Chapter IV (RDFIs), subsection F (Authorization and Agreements) 

Section IV, Chapter XI (Represented Check Entries), subsection D-2 (Notice Requirement) 

Section IV, Chapter XII (Point-of-Purchase Entries), subsection C-2 (Authorization Requirement) 

Section IV, Chapter XIII (Accounts Receivable Entries), subsection D-2 (Authorization/Notification 

Requirements) 

Section IV, Chapter XIV (Internet-Initiated Entries), subsection F-2 (Authorization Requirements) 

Section IV, Chapter XV (Telephone-Im tiated Entries), subsection D-2 (Authorization Requirements) 

AUTOMATED ENROLLMENT : .. : 

Provides Depository Financial Institutions (DFIs) with a mechanism to transmit enrollment information to 
Federal Government Agencies on behalf of both consumer and corporate account holders for future ACH 
credit and debit entries. 

Rules 

Article Two, subsection 2.1.7 Automated Enrollment Entries 

Appendix Two ACH Record Format Specifications 

Guidelines 

Section II, Chapter I (Originators), subsection D (Automated Enrollment) 

Section IV, Chapter VIII (Automated Enrollment Entries) 

AVAILABILITY OF ENTRIES :\ :■ 

■■Defines the rules governing when entries are made available to an RDFI or to an RDFI' s Receiving Point. 

Also defines the time frames under which an RDFI must post entries and provide funds availability for such 

.entries. .:■'.:■.' 

Rules ';■■.'■ 

Article Four, section 4.3 Receipt and Availability of Entries 

Article Four, section 4.4 Availability of Entries and Entry Information, Crediting and Debiting of 

..v. Entries' ■ 
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Guidelines 

Section II, Chapter I (Originators), subsection L-3 (Relationship with ODFI) 

Section II, Chapter IV (RDFIs), subsection C (Receipt and Processing of ACH Files), subsection D (Posting 

and Funds Availability) 

Refers to frequently used codes within theNACHA Operating Rules mdNACHA Operating Guidelines, 

Rules ■: ' 

Appendix Two, section 2.2 Code Values - Addenda Record Indicator 

Addenda Type Codes 

Card Transaction Type Codes 

Item Type Indicator 

Originator Status Codes 

Record Type Codes 
* Service Class Codes 

Standard Entry Class Codes 

Transaction Codes 

Appendix Three, section 3.6 Automatic Entry Detail Return Entry (ACH Operator Return Reason 

: Codes) 

Appendix Five, section 5.4 Table of Return Reason Codes 

Appendix Six, section 6.5 Table of Change Codes 

Appendix Seven, section 7.3 Table of Codes for Refused Acknowledgment Entries 

Guidelines /- v 

Section III, Chapter I (Prenotification), subsection D-l (Receiving and Identifying Prenotifications) 
Section III, Chapter II (Notifications of Change), subsection B-2 (Reasons for Change), subsection B^-^ 
(Returned and Refused Notifications of Change), subsection C (Responsibilities of ODFIs) 
Section III, Chapter III (Returns), subsection C-3 (Dishonored Returns), subsection D-l (Returns Initiated 
by ACH Operator), subsection E-1 (Returns), subsection E-3 (Originating Contested Dishonored Returns) 

COMPENSATION 

Provides for the settlement of claims for compensation between Participating DFIs. 

.■ Rules ■.;■;.'■■.■.'.■>.':■■■.■': 
Article One, subsection 1.2.2 Compensation 
Appendix Nine Compensation Rules 

Guidelines . 

Section IV, Chapter VI (Arbitration and Compensation) 

CONSUMERACCOUNTS-VAmABLEAMOUNTSANDDATES^^^;:^;:;;^^^::^^;^^^;^^^:^^^;^;;; > 
Defines specific notice requirements that Originators must provide to consumers when changes occur in the 
scheduled date or amount of a prearranged debit to the consumer's account. 

Article Three, section 3. 4 Consumer Accounts -Notice by Originator to Receiver of Variable Debits 
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CROSS-BORDER ENTRIES 

Defines the application of the NACHA Operating Rales to ACH payments exchanged between payment 
system participants of different countries. 

Rules 

Article Eleven Cross-Border Payments 

Appendix Two ACH Record Format Specifications 

Guidelines 

Section II, Chapter I (Originators), subsection E (Cross-Border Entries) 
Section II, Chapter II (ODFIs), subsection E (Cross-Border Entries) 
Section II, Chapter IV (RDFIs), subsection C-3 (Processing of ACH Files) 
Section IV, Chapter X (Cross-Border Payments) 

DATA SECURITY REQUIREMENTS 

The NACHA Operating Rules require, at a minimum, the use of 128-bit RC4 encryption technology, or its 
equivalent, for the transmission or exchange of any banking information related to ACH entries when that 
information is transmitted or exchanged via an Unsecured Electronic Network. 

Rules : 

Article One, section 1.5 Transmission of ACH Information Via Unsecured Electronic Networks 

Article Two, section 2.2. 1.6 Transmission of ACH Information Via Unsecured Electronic Networks 
Article Three, section 3.3 Transmission of ACH Information Via Unsecured Electronic Networks 

Article Fourteen, section 14.1.64 Unsecured Electronic Network 
■.■AppmdixEight v 'sectioii 

Guidelines 

Section II, Chapter I (Originators), subsection L-2 (ACH Data Security Requirements) 

Section II, Chapter II (ODFIs), subsection K-3 (ACH Data Security Requirements) 

Section II, Chapter III (ACH Operators), subsection D-3 (ACH Data Security Requirements) 

Section II, Chapter IV (RDFIs), subsection C-3 (Processing of ACH Files) 

Section IV, Chapter XIV (Internet-Initiated Entries), subsection E (ACH Data Security Requirements) 

DEATH NOTIFICATION ENTMES- 

Entry used by Federal Government Agencies as a notice to RDFIs that an account holder of the RDFI is 
deceased. Conveys information relating to the Receiver's date of death and Social Security Number. 

Rules .■:'■'.'■."■.■:■'.■ 

Article Four, section 4.9 RDFI Receipt of Death Notification Entry 

Appendix Two ACH Record Format Specifications 

Guidelines 

Section II, Chapter IV (RDFIs), subsection C-3 (Processing of ACH Files) 

DESTROYED CHECK ENTRIES 

Provides amechanismfor the ACH Network to be used by a collecting financial institution to collect an item 
that is contained within a cash letter that is lost, destroyed, or is otherwise unavailable to and cannot be 
obtained by the ODFI. 

Rules 

Article Two, subsection 2.1.3 Exception to Authorization Requirement 
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Article Two, subsection 2.2. 1.1 Authorization by Originator and Receiver 
Article Two, section 2 .7 Destroyed Check Entries 

Guidelines 

Section II, Chapter II (ODFIs), subsection O (Destroyed Check Entries) 
Section II, Chapter IV (RDFIs), subsection C-3 (Processing of ACH Files) 
Section IV, Chapter IX (Destroyed Check Entries) 

ELECTRONIC COMMUNICATIONS/ELECTRONIC W^COM)S^:^^^^^^: ^ / 

ThsNACHA Operating Rules permit the use of electronic agreements and the electronic storage of records 
in conformance with the Electronic Signatures in Global and National Commerce Act (E-Sign Act). The 
rules allow any agreement, authorization, affidavit, or other record (e.g., notice, disclosure, etc.) that is 
required by the NA CHA Operating Rules tobe in writing to be executed in either in paper or electronic 
format When a signature is required on any writing, such a document may either be signed or similarly 
authenticated by the same means required for authorization of consumer debits. 

■ Rules 

Article One, section 1.6 Records 

Article Fourteen, subsection 14.1 .20 Electronic 

Article Fourteen, subsection 14.1.21 Electronic Record 

Article Fourteen, subsection 14.1 .22 Electronic Signature 

Article Fourteen, subsection 14.1.46 Record 

Guidelines 

Section II, Chapter I (Originators), subsection B-1 (Electronic Records and Electronic Record Retention) 
Section Tl', Chapter II (ODFIs), subsection C-2 (Electronic Records and Electronic Record Retention) 
Section II, Chapter III (ACH Operators), subsection C-l (Electronic Records and Electronic Record 

■ Retention)'- :'■ [ ■.'■:■ '■;■ ■ 

Section II, Chapter IV (RDFIs), subsection F-1 (Electronic Records and Electronic Record Retention) 
Section IV, Chapter I (Third-Party Service Providers), subsections C-l (Agreements) and D-l (Agreements) 
Section W, Chapter XIV (Internet-Initiated Entries), subsection F-2 (Authorization Requirements) 

EXCUSED DELAY . .■■■:■■ '■■. 

Clarifies the circumstances under which a processing delay by a DFI or ACH Operator would be excused. 

. Rules 
Article One, section 1 .3 Excused Delay 

Guidelines 

Section II, Chapter II (ODFIs), subsection K-5 (Excused Delay) 

Section II, Chapter rV (RDFIs), subsection C-5 (Excused Delay) 

FORMATS and FILE STRUCTURE 

Refers to the technical specifications and formatting requirements for all ACH entries. 



Rules '■■■.■.'■:■;.'.■. 

Article Two, section 2.13 Media and Format Specification Requirements 

Appendix One ACH File Exchange Specifications 

Appendix Two ACH Record Format Specifications 

AppendixFive Return Entries 

AppendixSix Notification of Change 
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Appendix Seven 



Acknowledgment Entries 



Guidelines : 

Section II, Chapter I (Originators), subsection L-1 (Transaction Codes) 

Section II, Chapter II (ODFIs), subsection K-l (Transaction Codes) 

Section II, Chapter IV (RDFIs), subsection C-l (Transaction Codes) 

Section III, Chapter I (Prenotifications), subsection D-l (Receiving and Identifying Prenotifications) 

Section III, Chapter II (Notifications of Change), subsection B-l (Origination of Notifications of Change), 

B-2 (Reasons for Change), B-6 (Returned and Refused Notifications of Change), C (Responsibilities of 

ODFIs) 

Section III, Chapter III (Returns, Dishonored Returns, and Contested Dishonored Returns) 

Section IV, Chapter VIII (Automated Enrollment Entries) 




FUNDS AVAILABILITY 

Defines the rules governing an RDFFs requirements to provide funds availability for credit entries posted 
to a Receiver's account. 

Rules .■'■.; 

Article Four, subsection 4.4.1 Availability of Credit Entries to Receivers 

Guidelines 

Section II, Chapter IV (RDFIs), subsection C-2 (Delivery of ACH Files), subsection D (Posting and Funds 

Availability)';-; 

INDEMNIFICATION. ,,v.. : 

Addresses liability/indemnification requirements and limitations unique to various types of ACH paympnt^ 

Rules ; ; 

Article Two, subsection 2.4.5 Indemnifications (Reversing Files) 
Article Two, subsection 2.5.2 Indemnifications (Reversing Entries) 

Guidelines ■ ■ 

Section IV, Chapter I (Third-Party Service Providers), subsection C-2 (Warranties and Indemnifications), 

subsection D-2 (Warranties and Indemnifications) 

INTERNET-INITIATED ENTRY : - ',■'. -^ 

A debit entry to a consumer account that is initiated pursuant to an authorization obtained from the Receiver 
via the Internet. 



Rules 

Article Two, subsection 2.1.2 

Article Two, section 2.10 

Article Three, section 3.9 

Article Eight, section 8.4 

Article Fourteen, subsection 14.1.56 

Article Fourteen, subsection 14.1.63 

Appendix One, section 1 .4 

Appendix Two 

Appendix Three , section 3 .6 

Appendix Five, section 5.4 

Appendix Eight, section 8.3 



Receiver Authorization and Agreement 

Internet-Initiated Entries 

Obligations of Originators of Internet-Initiated Entries 

Stop Payment Affecting Consumer Accounts 

"Single Entry" 

"WEB entry" 

Sequence of Records in ACH Files 

ACH Record Format Specifications 

Automatic Entry Detail Return Entry 

Table of Return Reason Codes 

Audit Requirements for ODFIs 
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Guidelines 

Section II, Chapter I (Originators), subsection I (Internet-Initiated Entries) 
Section II, Chapter II (ODFIs), subsection I (Internet-Initiated Entries) 
Section II, Chapter IV (RDFIs), subsection C-3 (Processing of ACH Files) 
Section IV, Chapter XIV (Internet-Initiated Entries) 

NOTIFICATION OF CHANGE 

A non-dollar ACH transaction transmitted by an RDFI to an ODFI/Originator to request a change of 
erroneous information contained within an ACH entry. 

Rules 

Article Six, section 6.3 Notification of Change 

Article Six, section 6.4 Refused Notification of Change 

Appendix Six Notification of Change 

Guidelines 

Section II, Chapter I (Originators), subsection L-3 (Relationship with ODFI) 

Section II, Chapter II (ODFIs), subsection L-3 (Returns/Reinitiated Entries/NOCs/Rejected Files) 

Section III, Chapter II (Notification of Change) 

ODFI EXPOSURE LIMITS 

Risk management procedure required by the NACHA Operating Rules. Requires each ODFI to establish 
credit/exposure limits for each Originator, to implement procedures to review those limits periodically, and 
to implement procedures to monitor entries initiated by a given Originator relative to its exposure 1 imit across 
multiple settlement dates. Also requires implementation of procedures by ODFIs to monitor the payments 
system risk associated with cross-border entries, as well as the implementation of exposure limits specific 
to the origination of Internet-Initiated Entries. 

Rules 

Article Two, subsection 2.1.10 ODFI Exposure Limits 

Article Two, subsection 2. 10.2.3 ODFI Exposure Limits 

Appendix Eight, Section 8.3 Audit Requirements for ODFIs 

Guidelines 

Section II, Chapter II (ODFIs), subsection C-3 (Agreement/Relationship with Originator) 

OFAC REGULATIONS 

Originators of ACH entries must be aware that they are subject to applicable U.S. law when originating ACH 
payments. This includes, among other things, that the Originator is not violating the Office of Foreign Assets 
Control (OFAC)-enforced sanctions, and is not acting on behalf of, or transmitting funds to or from, any 
party subject to such sanctions. 

Rules 

Article Two, subsection 2.1.1 Originator Authorization and Agreement 

Guidelines 

Section II, Chapter I (Originators), section B-2 (Relationship with ODFI), section L-3 (Relationship with 

ODFI) 

Section II, Chapter II (ODFIs), section C-3 (Agreements/Relationship with Originator) 

Section II, Chapter IV (RDFIs), section C-3 (Processing of ACH Files) 

Section IV, Chapter III (OFAC Compliance) 



QUICK FIND 8 



2005 ACH RULES QUICK FIND 

PERIODIC STATEMENTS \ . . .;:.:; 

Provides specific information concerning an RDFI' s requirement to send or make available to each Receiver 

information concerning each credit and debit entry to a consumer account. 

Rules 

Article Four, section 4.5 Periodic Statements 

Appendix Four Minimum Description Standards 

POINT OF PURCHASE ENTmES;;:;:.;: ;.v^\ 

Single Entry debits to a consumer account for the in-person payment of goods or services. The consumer's 

source document (i.e., the check) is used to collect the consumer's routing number, account number, and 

check serial number for the payment, which is authorized, in writing, by the consumer at the time of 

purchase.' 

■ Rules . 

Article Two, subsection 2. 1.2 Receiver Authorization and Agreement 

Article Two, subsection 2.2. 1 .1 1 Pomt-of^Purchase Entries 

Article Three, section 3 .8 Obligations of Originators of POP Entries 

Article Eight, section 8.4 Stop Payment Affecting Consumer Accounts 

Article Eight, subsection 8.6.2 Receiver's Right to Recredit for POP Entries 

Article Eight, subsection 8.6.5.2 Receiver's Written Statement Under Penalty of Perjury for POP 

■ ■ Entries Y ; 

Article Eight, subsection 8.7.2 RDFI's Right to Adjustment for POP Entries 

Appendix Two, section 2.3 Glossary of File Format Data Elements 

Guidelines 

Section I, Chapter I (Originators), section F (Point-of-Purchase Entries) 
Section I, Chapter II (ODFIs), section F(Point-of-Purchase Entries) 
Section I, Chapter IV (RDFIs), section C-3 (Processing of ACH Files) 
Section IV, Chapter XII (Point-of-Purchase Entries) 

: PRENOTIFICATION ^::] : : : ■:[:■:;.: 

A non-dollar entry transmitted by an Originator to an RDFI to allow the RDFI to verify the accuracy of the 
account data prior to the transmission of live entries. V 

Rules .■'.■.■■:■■.■':.'.■.■■.'; ; - 

Article Two, section 2.3 Prenotification 

Article Four, subsection 4. 1.2 Obligation to Verify Prenotification 

Article Four, subsection 4.1.3 Obligation to Accept Entries 

Guidelines 

Section II, Chapter I (Originators), subsection K (Prenotification) 
Section II, Chapter IV (RDFIs), subsection C-3 (Processing of ACH Files) 
Section III, Chapter I (Prenotifications) 
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reclamation: ■ ■ v : 

An Originator or ODFI may transmit a reclamation entry for a pension, annuity, or other benefit payment 
made following the death of the Receiver and to which neither the Receiver's estate nor any other account 
holder is entitled. 

Rules ■ 

Article Two, subsection 2.2. 1.10 Reclamation Entries 

Article Two, section 2.6 Reclamation Entries 

Article Four, section 4.8 Liability of RDFI for Benefit Payments 

Appendix Two ACH Record Format Specifications 

Guidelines 

Section III, Chapter IV (Reversals), subsection C (Reclamations for Benefit Payments) 

(See The Green Book for Federal Government Reclamations) 

. RECORD RETENTION- :.. : 

The NACHA Operating Rules mandate specific retention periods for records of ACH entries processed by 

each ODFI, ACH Operator, and RDFI. 

Rules 

Article One, section 1.6 Records 

Article Three, section 3,12 Record of Authorization 

Article Nine, section 9.9 Record of Entries 

Guidelines 

Section II, Chapter I (Originators), subsection B-3 (Relationship with Receiver) 

Section IV, Chapter XI (Re-presented Check Entries), subsections D-6 (Retention of Copy of Item) and E-4 

(Retention of Copy of Item) 

Section IV, Chapter XIII (Accounts Receivable Entries), subsections D-6 (Retention of Source Document) 

and E-5 (Retention of Source Document) 

REINITIATION OF ENTRIES 

In general, ACH entries that are returned by the RDFI may not be reinitiated unless (1) the entry has been 
returned for insufficient or uncollected funds; (2) the entry has been returned for stopped payment and 
reinitiation has been authorized by the Receiver; or (3) the ODFI has taken corrective action to remedy the 
reason for the return. An entry that has been returned for insufficient or uncollected funds maybe reinitiated 
no more than two times following the return of the original entry. 

Rules ■ 

Article Two, section 2. 12 Reinitiation of Returned Entries by Originators 

Article Six, subsection 6.1.7 Reinitiation of Return Entnes by ODFI 

Guidelines 

Section II, Chapter I (Originators), subsection L-3 (Relationship with ODFI) 

Section II, Chapter II (ODFIs), subsection L-3 (Returns, Reinitiated Entries, NOCs, Rejected Files) 

Section III, Chapter III (Returns), subsections B-2 (Reinitiation of Returned Entries) and C-2 (Reinitiation 

of Returned Entries) 

Section IV, Chapter IX (Cross-Border Payments), subsection C-2 (National Payment System Rules) 
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RELIANCE ON ACCOUNT NUMBER AND STANDARD ENTRY CLASS CODE FOR POSTING 

If the account number and the name of the Receiver contained in an entry do not relate to the same account, 
the RDFImay rely solely on the account number contained in the entry for purposes of posting the entry to 
the Receiver's account. An RDFI may rely on the Standard Entry Class Code contained in an entry for 
purposes of determining which rules and processing requirements govern the handling of that payment. 



■ 



Rules 

Article Four, subsection 4.1.4 

Article Four, subsection 4.4.6 



Reliance on Account Numbers for Posting of Entries 
Reliance on Standard Entry Class Codes 



RE-PRESENTED CHECK ENTRIES 

Provides the mechanism for an Originator to convert a check that has been returned for insufficient or 
uncollected funds into an ACH debit entry and re-present it through the ACH Network for collection. 



Rules 

Article Two, subsection 2.1.5 
Article Two, section 2.8 
Article Two, section 2.12 
Article Three, section 3.6 
Article Four, subsection 4.1.1 
Article Four, section 4.2 
Article Six, subsection 6.1.2 
Article Six, subsection 6.1.7 
Article Eight, section 8.4 
Article Eight, subsection 8.6.3 
Article Eight, subsection 8.6.5.3 

Article Eight, subsection 8.7.3 
Article Eight, subsection 8.7.5 
Article Eight, subsection 8.7.6 
Article Fourteen, subsection 14.1.24 
Article Fourteen, subsection 14. 1.45 
Appendix Two 



Notification for Re-presented Check Entries 

Re-presented Check Entries 

Reinitiation of Returned Entries by Originator 

Obligations of Originators of RCK Entries 

Right to Information Regarding Entries 

Warranties of Receiving Depository Financial Institutions 

Requirements of Returns 

Reinitiation of Return Entries by ODFI 

Stop Payment Affecting Consumer Accounts 

Receiver's Right to Recredit for RCK Entries 

Receiver's Written Statement Under Penalty of Perjury for RCK 

Entries 

RDFFs Right to Adjustment for RCK Entries 

Warranty of RDFI 

Copy of Written Statement Under Penalty of Perjury 

"Entry" 

"RCK Entry" 

ACH Record Format Specifications 



Guidelines 

Section II, Chapter I (Originators), subsection G (Re-presented Check Entries) 
Section II, Chapter II (ODFIs), subsection G (Re-presented Check Entries) 
Section II, Chapter IV (RDFIs), subsection C-3 (Processing of ACH Files) 
Section IV, Chapter XI (Re-presented Check Entries) 



ACH entries may be returned for a variety of reasons. The ACH Network also supports the dishonor and 
contesting of a dishonored return. 



Rules 

Article Two, subsection 2.8.4 
Article Six, section 6.1 
Article Six, section 6.2 
Article Ten, section 10.3 
Appendix Five 



Return of a Re-presented Check Entry 

Return of Entries 

Dishonor of Return Entries 

Return and Rej ection by an ACH Operator (TRC, TRX entries) 

Return Entries v 
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Guidelines 

Section II, Chapter I (Originators), subsection L-3 (Relationship with ODFI) 

Section II, Chapter II (ODFIs), subsection L-3 (Returns/Reinitiated Entries/NOCs/Rejected Files) 

Section III, Chapter III (Returns, Dishonored Returns, Contested Dishonored Returns) 

REVERSALS ~' : : '' '■ ' y 

File reversals may be originated to correct a duplicate or erroneous file in which substantially all of the 
entries are incorrect. A reversing entry may be originated to con-ect an entry that is a duplicate of an entry 
previously initiated by the Originator or ODFI, that orders payment to or from a Receiver not intended to be 
credited or debited by the Originator, or that orders payment in a dollar amount different than was intended 
by the Originator/ 

Rules 

Article Two, section 2.4 Reversing Files 

Article Two, section 2.5 Reversing Entries 

Guidelines 

Section III, Chapter IV (Reversals, Reclamations, ODFI Requests for Return) 

RULES ENFORCEMENT ; -- :; 'V 

The rules enforcement process provides a formal mechanism for the documentation and investigation ol 

alleged violations of the NACHA Operating Rri 

of ACH services and the satisfaction of Participating DFIs and their customers by ensuring compliance by 

Participating DFIs with the provisions of the NACHA Operating Rules . 

■ Rules ■.'■ 

Article One, subsection 1 .2.4 Rules Enforcement 
Appendix Eleven Rules Enforcement 

Guidelines 

Section IV, Chapter V (National System of Fines) 

Related Topics: Audit Controls and Compliance 

, STOP PAYMENT ;■.... ^ 
A Receiver may stop the payment of any one ACH entry by placing a stop payment order for that entry with 

■ theRDFI. 

Article Two, section 2. 12 Reinitiation of Returned Entries by Originators 

Article Six, subsection 6.1.7 Reinitiation of Returned Entries by ODFIs 

Article Eight, section 8.4 Stop Payments Affecting Consumer Accounts 

Article Eight, section 8.5 Stop Payments Affecting Non-Consumer Accounts 

STOP PAYMENTS vs. REVOCATfe^ 

A stop payment order is intended to stop the payment of one ACH entry only, similar to a stop payment order 

placed on a check. To stop all future ACH activity relating to a specific authorization, a Receiver must 

revoke (i.e., cancel) the original authorization directly with the Originator m the manner specified on the 

authorization. 
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Guidelines 

Section II, Chapter I (Originators), subsection B-3 (Relationship with Receiver) 

Section III, Chapter III (Returns), subsection E-l (Returns) 



TELEPHONE-INITIATED ENTRY 

A debit entry to a consumer account that is initiated pursuant to an authorization obtained from the Receiver 
orally via the telephone. 




Rules 

Article Two, subsection 2.1.6 

Article Two, section 2. 1 1 

Article Three, section 3.9 

Article Three, section 3.12 

Article Eight, section 8.4 

Article Fourteen, subsection 14.1.26 

Article Fourteen, subsection 14.1.57 

Appendix Two 

Appendix Three, section 3.6 

Appendix Five, section 5.4 

Appendix Eight, section 8.3 



Authorization for Telephone-Initiated Entries 

Telephone-Initiated Entries 

Obligations of Originators of Telephone-Initiated Entries 

Record of Authorization 

Stop Payment Affecting Consumer Accounts 

"Existing Relationship" 

'TEL Entry" 

ACH Record Format Specifications 

Automatic Entry Detail Return Entry 

Table of Return Reason Codes 

Audit Requirements for ODFIs 



Guidelines 

Section II, Chapter I (Originators), subsection J (Telephone-Initiated Entries) 
Section II, Chapter II (ODFIs), subsection J (Telephone-Initiated Entries) 
Section II, Chapter IV (RDFIs), subsection C-3 (Processing of ACH Files) 
Section IV, Chapter XV (Telephone-Initiated Entries) 



THIRD-PARTY SENDER 

A Third-Party Sender is a person that is not an Originator that has authorized an ODFI or another Third-Party 
Sender to transmit, for the account of the Third-Party Sender or another Third-Party Sender, (i) a credit entry 
to the account of a Receiver with an RDFI, or, if the Receiver is also the RDFI, to such Receiver, in order 
to effect a payment from the Originator to the Receiver, or (ii) a debit entry to the Receiver^ 
account or general ledger account with an RDFI, or, if the Receiver is also the RDFI, to such Receiver,^ 
order to effect a payment from the Receiver to the Originator. 



Rules .';':■'-. 

Article Two, subsection 2.1.1 
Article Two, subsection 2.1.10 
Article Two, subsection 2.2.1.4 
Article Two, subsection 2.10.2.3 
Article Three, section 3.11 
Article Five 

Article Eleven, section 11.2 
Article Fourteen, subsection 14.1.37 
Article Fourteen, subsection 14.1.58 
Appendix Eight, section 8.3 



Originator Authorization and Agreement 

ODFI Exposure Limits 

Revocation of Authorization 

ODFI Exposure Limits 

Payment to ODFI 

Obligations of Third-Party Senders 

Originator/ODFI Agreement 

definition of "Originator" 

definition of "Third-Party Sender" 

Audit Requirements for ODFIs 



Guidelines 

Section II, Chapter II (ODFIs), subsection C (Legal Considerations) 
Section II, Chapter II (ODFIs), subsection N (Audit Requirements) 
Section IV, Chapter I (Third-Party Service Providers) 
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THIRD-PARTY SERVICE PROVIDER 

A third-party service provider is an organization other than the Originator, ODFI, or RDFI that performs a 
function of ACH processing on behalf of that Originator, ODFI, or RDFI. A third-party service provider 
could be a data processing service bureau, a correspondent bank, a payable-through bank, or simply a 
financial institution acting on behalf of another financial institution. 

Rules : : 

Article Two, subsection 2.2.1.11 Sending Points 

Article Two, subsection 2.2.4 Sending Points 

Article Four, section 4.3 Receipt and Availability of Entries 

Article Fourteen, subsection 14.1.51 Receiving Point 

Article Fourteen, subsection 14.1.53 Sending Point 

Appendix Eight - Rule Compliance Audit Requirements 

Guidelines 

Section IV, Chapter I (Third-Party Service Providers) 

UCC4A;':'.-; '■■■'..■■'.■■■■' 

State law governing wholesale (i.e., corporate-to-corporate) ACH credit entries. 

Rules 

Article One, section 1.7 Choice of Law 

Article Two, subsection 2. 1.8 Notice by ODFF 

Article Two, subsection 2. 1 .9 Notice by RDFI 

Article Four, subsection 4.4.7 Reimbursement of RDFI 

Guidelines 

Section II, Chapter I (Originators), subsection B-2 (Relationship with ODFI) 

UNAUTHORIZED ENTRIES ': ; ; , : . : ^,. ^ 

An entry ( 1 ) for which the authorization requirements, as prescribed by the NA CHA Operating Rules, have 
not been met; (2) that was initiated in an amount greater than was authorized by the Receiver; or (3) that wa^ 
initiated for settlement earlier than authorized by the Receiver. 

Rules 



Article Two, section 2.2 Warranties and Liabilities of ODFI 

Article Four, subsection 4.4.5 Rights of Receiver Upon Unauthorized Debit to Its Account 

Article Eight, section 8.6 Receiver's Right to Recredit 

Appendix Five Return Entries (see Table of Return Reason Codes) 

Guidelines 

Section II, Chapter I (Originators), subsection B-3 (Relationship With Receiver) 

Section II, Chapter II (QDFIs), subsection L-3 (Returns/Reinitiated Entries/NOCs/Rejected Fil^ 

Section II, Chapter IV (RDFIs), subsection F (Authorizations and Agreements); (see also Sample Written 

Statement Under Penalty of Perjury within this chapter on RDFIs) 

Section III, Chapter HI (Returns, Dishonored Returns, and Contested Dishonored Returns) 
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WARRANTIES AND LIABILITIES 

The ODFLis responsible for all transactions it originates into the ACH Network, assuming specific 

warranties and liabilities relating to the origination of each entry. 

Rules ■..'.■ 

Article Two, section 2.2 Warranties and Liabilities of Originating Depository Financial Institutions 

Article Two, subsection 2 .7.3 Warranties (Destroyed Check Entries) 

Article Two, subsection 2.8.3 ODFI Warranties (RCK Entries) 

Article Two, subsection 2.9.3 ODFI Warranties (Accounts Receivable Entries) 

Article Two, subsection 2.10.2 ODFI Warranties (Internet-Initiated Entries) 

Article Four, section 4.2 Warranties of Receiving Depository Financial Institutions 

Article Four, section 4.8 Liability of RDFI for Benefit Payments 

Article Six, subsection 6.3.1 Notification of Change; RDFI Warranties and Indemnity 

Article Eight, subsection 8.7.5 Warranty of RDFI (Adjustment Entries) 

Article Ten, section 10.2 Eligible Participants and Warranties 

Article Twelve, section 12.1 Warranties of Associations 

Article Twelve, section 12.3 Association Liability for Negligence and Willful Misconduct of Its ACH 

Operator 

Guidelines 




Section II, Chapter II (ODFIs), subsection C-l (Warranties and Indemnifications), subsection C-4 

(Agreements/Relationship With Third-Party Service Provider), subsection L-3 (Returns, Reinitiated Entries, 

NOCs, and Rejected Files) -see "Unauthorized Consumer Debits" 

Section IV, Chapter I (Third-Party Service Providers), subsection C-2 (Warranties and Indemnifications), 

subsection D-2 (Warranties and Indemnifications) 

Section IV, Chapter XI (Re-presented Check Entries), subsection E-l (Warranties and Liabilities) 

Section IV, Chapter XII (Point-of-Purchase Entries), subsection D-l (Warranties and Liabilities) 

Section IV, Chapter XIII (Accounts Receivable Entries), subsection E-l (Warranties and Liabilities) 

Section IV, Chapter XIV (Internet-Initiated Entries), subsection G-2 (Warranties and Liabilities) 

Section IV, Chapter XV (Telephone-Initiated Entries), subsection E-l (Warranties and Liabilities) 

WRITTEN STATEMENT UNDER PENALTY OF PERJURY - 

A consumer requesting recredit for debit entries (1 ) that the consumer claims are unauthorized, (2) for which 

authorization has been revoked, or (3) that were improperly originated will be required to sign or similarly 

authenticate a written statement under penalty of perjury. RDFI warrants that it has obtained the consumer' s 

written statement under penalty of perjury prior to transmitting a return using Return Reason Codes R07 

R10,R37,R51,andR53. 

Rules .'■ 

Article Eight, subsection 8.6 Receiver's Right to Recredit 

Article Eight, subsection 8.7 Adjustment Entries 

Guidelines 

Section II, Chapter IV (RDFIs) Sample Written Statement Under Penalty of Perjury 
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2005 OPERATING RULES REVISIONS 



HOW TO IMPLEMENT THE REVISIONS 

TO THE NACHA OPERATING RULES AND GUIDELINES 

The following pages highlight the rule amendments incorporated .. into this publication of the NACHA 
Operating Rules and NACHA Operating Guidelines. A summary of the 2005 revisions follows, explaining 
the rule amendments and offering suggestions on their implementation. The following material provides 
information on two amendments to the NACHA Operating Rules that will become effective on March 1 8, 
2005. 

Also included are summaries of four rule amendments to the NACHA Operating Rules that were approved 
after the publication of the 2004 edition of the ACH Rules: A Complete Guide to Rules & Regulations 
Governing the ACH Network. Ont amendment became effective on June 1 1 ,2004, two amendments became 
effective on September 10, 2004, and one amendment became effective on December 10, 2004. Because 
these rule changes were issued as supplements to, rather than being included within, the bound edition of the 
2004 ACH Rules, an overview of each of these changes is included within this document for reference. 

After each subject are the pages within the NACHA Operating Rules that conespond 

Vertical markings (|) in the left m^ 

additions or wording changes) have taken place. The date of approval is noted in the bottom margin and is 

immediately followed by the effective date of the mle change. To accommodate nile amend 

become effective later in 2005, this edition contains both the current wording of the rule, followed by the new 

rule highlighted in brackets and italics. 

EFFECTIVE JUNE 11, 2004 

ARC Opt Out Requirements 

Modified the NACHA Operating Rules to require that Originators of ARC entries allow Receivers to opt out 
of ARC check conversion. 




Approved February 27, 2004; Effective June 11, 2004 

(OR30;/:V-:'-^ 



***** 



EFFECTIVE SEPTEMBER 10, 2004 

ACH Data Security Requirement?; 

Expanded data security requirements within the NACHA Operating Rules to require all ACH transactions, 
regardless of Standard Entry Class (SEC) Code, that involve the exchange or transmission of banking 
information via Unsecured Electronic Nelworks to be either (1) encrypted using a commercially 
security technology that, at a minimum, is equivalent to 128-bit RC4 encryption technology/ 
transmitted via a secure session utilizing a commercially reasonable security technology that provides a level 
of security that, at a minimum, is equivalent to 128-bit RC4 encryption technology. Such encryption 
technology must be used prior to the key-entry and through transmission of any banking information, and 
it applies to the transmission or exchange of banking information between: a Receiver and an Originator; an 
Originator and an ODFI; an ODFI and an ACH Operator; an ACH Operator arid an R^ 
ODFI, RDFI, or ACH Operator and a Third Party Service Provider. (Note: Prior to the implementation of 
this amendment, the requirement to utilize a secure Internet session was required only for the exchange of 
banking information between an Originator and a Receiver with respect to WEB transactions.) 
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Under this amendment, the Rules were also modified to define an Unsecured Electronic Network as a public 
or private network that is not located entirely within a single, contiguous, physical facility and any part of 
which that has not implemented security technologies that provide a level of security that, at a minimum, is 
equivalent to 128-bit RC4 encryption technology. Transmissions or exchanges of banking information by 
means of voice or keypad inputs from a wireline or wireless telephone are not subject to these requirements 
unless the telephone is used to access the Internet. For example, an application in which the Originator 
obtains information from the Receiver by another means (such as the telephone) and then key-enters the 
information via the Internet would be subj ect to these security requirements. However, information delivered 
via a telephone line, such as a leased line, or dialed into a financial institution's modem pool is not affected 
by this amendment. 

Approved December 2, 2003; Effective September 10, 2004 
(OR 1,5, 13, 37, 136, 137.) 

Returns Issues - ACH Operator Requirements 

Modified the NACHA Operating Rules to resolve two inconsistencies between the ACH Operators' practices 
related to return entries and the requirements of the Rules. Specifically, these changes, which largely 
impacted only the ACH Operators, (1) removed the ACH Operator mandatory field error edit on the Original 
Receiving DFI Identification Field within the addenda records of dishonored return and contested dishonored 
return entries since this field is defined as a required, rather than mandatory, field, and (2) established a 
requirement within the Rules that prohibits ACH Operators from settling return entries prior to the effective 
entry date in the Company/Batch Header record of the original entry, as reflected in the return Entry Detail 
Record. 

Approved December 2, 2003; Effective September 10, 2004 

(OR 82, 88.) 



***** 



EFFECTIVE DECEMBER 10, 2004 

Third-Party Service Provider Issues 

Modified the provisions of the NACHA Operating Rules to include specific obligations and processing 
requirements for certain types of Third-Party Service Providers (referred to as "Third-Party Senders") that 
act as intermediaries between an Originator and an ODFL 

The Rules require that an Originator and an ODFI have an agreement that, among other things, binds the 
Originator to the Rules. However, it is common business practice among some Originators and ODFIs to have 
agreements with a Third-Party Service Provider that stands between the Originator and the ODFI and acts 
in an intermediary capacity between these two parties. In such circumstances, the lack of a direct contractual 
relationship between the Originator and the ODFI has the potential to increase the risk incurred by the O 
since it may be unable to establish a claim against the Originator in the event of loss. TW 
established an appropriate legal framework within the Rules to accommodate this business arrangement (i.e. ; 
Originator-Third-Party Service Provider-ODFI), thus protecting ODFIs by ensuri^ 
bound to the "Rules and that the Third-Party Sende 

Specifically, the J?^^ (!) the Originator and ODFI have 

entered into a contractual agreement under which the Originator agrees to be bou^^ 

Operating Rules (as &^ 

has entered into an appropriate agreement imder which the Third-Party Sender is bora^ 

effect from time to time and acknowledges that entries may not be initiated that violate the laws of the United 

States, and the Originator has entered into an appropriate agreement under which the Originator has as 

the responsibilities of an Originator under these mles and has aclmowledged that entries may not be initiated 
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that violate the laws of the United States. Each Third-Party Sender is subject to the requirements of Article 
Five (Obligations of Third-Party Senders). 

Approved December 2, 2003; Effective December 10, 2004 

(OR 2, 4, 5, 11, 15, 18, 19, 29, 35, 37, 137.) 

EFFECTIVE MARCH 18, 2005 

Internet Issues 

Modifies the NACHA Operating Rules to (1) add a new ODFI warranty specific to the requirement that an 
Originator of WEB entries use commercially reasonable methods of authentication to verify the identity of 
the Receiver, and (2) uniquely identify this requirement under the Originator's obligations with respect to 
WEB entries. 

Approved November 9, 2004; Effective March 18, 2005 

(OR 3,5, 11, 13, 15, 136, 138.) 

Returns for Unauthorized Debits to Consumer Accounts Using a Corporate SEC Code 

Modifies the NACHA Operating Rules to reactivate Return Reason Code R05 to accommodate the return of 
unauthorized debit entries to consumer accounts when those debits were transmitted using a corporate 
Standard Entry Class Code. Enables RDFIs to apply the same rules for returning all unauthorized debits to 
consumer accounts, regardless of the SEC Code contained within the entry. 

Approved August 9, 2004; Effective March 18, 2005 

(OR 23, 24, 25, 90.) 
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ACH DATA SECURITY REQUIREMENTS 




Summary:/. 

Effective September 10, 2004, the NACHA Operating Rules were modified to expand the data security 
requirements within the NA CHA Operating Rules to require all ACH transactions, regardless of Standard 
Entry Class (SEC) Code, that involve the exchange or transmission of banking information via Unsecured 
Electronic Networks to be either (1) encrypted using a commercially reasonable security technology that, 
at a minimum, is equivalent to 128-bit RC4 encryption technology, or (2) transmitted via a secure session 
utilizing a commercially reasonable security technology that provides a level of security that, at a minimum, 
is equivalent to 128-bit RC4 encryption technology. 

Such encryption technology must be used prior to the key-entry and through transmission of any banking 
information (which includes ACH entries, entry data, routing numbers, and PINS and other identification 
symbols), and it applies to the transmission or exchange of banking information between: a Receiver and an 
Originator; an Originator and an ODFI; an ODFI and an ACH Operator; an ACH Operator and an RDFI; and 
an Originator, ODFI, RDFI, or ACH Operator and a Third Party Service Provider. 

Under this amendment, the Rules were modified to define an Unsecured Electronic Network as a public or 
private network that is not located entirely within a single, contiguous, physical facility and any part of which 
that has not implemented security technologies that provide a level of security 
equivalent to 128-bit RC4 encryption technology. Transmissions or exchanges of banldng 
voice or keypad inputs from a wireline or wireless telephone are not subject to ^^^m^^ 
requirements unless the telephone is used to access the mtemet. For example, an application in which 
Originator obtains information from the Receiver by another means (such as the telephone) and then key- 
enters the information via the Internet is subject to these security requirements. However, information 
delivered via a telephone line, such as a leased line, or dialed into a financial institution's modem pool is not 
affected by this amendment. 

This amendment also modified the Rules to require ODFIs to employ commercially reasonable methods to 
establish the identity of each Originator that uses an Unsecured Electronic Network, such as the Internet, to 
enter into a contractual relationship with the ODFI for the origination of ACH transactions. This amendment 
helps to mitigate the increased risk of fraud associated with both single-entry transactions and remotely 
originated payments by ensuring that ODFIs take measures to know the customers with whom they establish 
relationships remotely and to verify those identities. 

Background 

Prior to the implementation of this amendment, the NACHA Operating Rules defined specific data security 
requirements only for entries bearing the WEB Standard Entry Class Code, requiring the use of 128-bit (or 
equivalent) encryption technology for any banking information exchanged between an Originator and a 
Receiver via the Internet. Although these requirements were a critical first step toward addressing security 
issues related to ACH transactions authorized over the Internet, the use of the Internet for the exchange of 
payment information in general raised security concerns for the ACH Network that go beyond the 
authorization for consumer payments . For example, any financial institution or Originator with a web server 
must be aware of potential vulnerabilities that could impact the security and integrity of any or all ACH 
information stored on that server. In addition, both financial institutions and Originators must consider the 
security of transmissions of ACH files between themselves and Third-Party Service Providers. These 
security concerns exist regardless of whether the payment information was obtained via the Internet or not. 
In addition, the proper authentication of all Originators (rather than just Originators of WEB entries) that 
enter into ACH agreements over an Unsecured Electronic Network must also be considered. 
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Impact to Participants: ; '■ ; : V'\;' : .- 

All Participants (Qriginators/ODFIs/ACH Qperators/RDFls/Third-Partv Service Providers! 

This amendment impacts those Originators, ODFIs, ACH Operators, RDFIs, and Third-Party Service 
Providers that exchange banking information (i.e., ACH entries, entry data, routing numbers, account 
numbers, PINs or other identification symbols) via Unsecured Electronic Networks, such as the Internet, and 
that have not already implemented a commercially reasonable security teclmolo^ 
security that, at a minimum, is equivalent to 128-bit RG4 encryption technology. Thes 
need to employ such data security capabilities (which must be employed prior to key entry and through 
transmission of any banking information) for the exchange or transmission of banking information involving 
the use of these types of networks. 

ODFIs 

In addition to examining their data security practices, ODFIs also need to ensure that they have established 
commercially reasonable methods to verify the identity of all Originators that utilize an Unsecured Electronic 
Network to enter into a contractual relationship with the ODFI for the originat^^ 

Software Changes for ACH Operators: This change had no impact on ACH Operators since they 
already require the use of 1284)itRC4encryptio 

Software Changes for Participating Depository Financial Institutions: ODFb and RDFIs 

that do hot currently employ the use of 1 2 84>itRC4 encryption technology (or its equiva^^ 
transmission or exchange of banking information via Unsecured Electronic Networks must ensure that their 
software incorporates such data security capabilities, which must be employed prior to the key entry and 
through the transmission of any banking information between ACH participants. 

Implementation Date: Septei^ 

(See.alsopagesORl,5,13^ 
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ARC OPT OUT REQU^^ 

Effective June 1 1 , 2004, the NA CHA Operating Rules were modified to require Originators of ARC entries 
to allow Receivers to opt out of ARC check conversion 

reasonable procedures under which Receivers may notify Originators that their checks are not to be converted 
to ARC entries. 

Impact to Participants: 

Originators 

Originators must ensure that they have established a mechanism to enable their customers to opt out of ARC 
check conversion and that such a mechanism employs reasonable procedures by which Receivers may notify 
Originators that their checks are not to be converted to ARC entries. The Rules do not prescribe specific 
procedures that an Originator must employ to allow a Receiver to opt out; rather, Originators may establish 
their own reasonable policies and practices for 

specific checking account. Originators must be aware that a Receiver's request to opt out of any ARC 
activity involving a particular checking account must remain in effect unless or until the Receiver notifies 
the Originator otherwise ..-' Originators may not require a Receiver to opt out for each check drawn on that 
account and need to ensure that they have established procedures to apply such opt out requests to all checks 
involving that Receiver's parto 

This rule change does not require Originators to provide notice to Receivers concerning their opt out rights 
with respect to ARC entries; however, in the spirit of good customer service and to foster the acceptance of 
check conversion activity, Originators are strongly encouraged to notify Receivers of their right to opt out 
and to provide the Receiver with a telephone number for any inquiries with respect to the ARC application 
in addition to a notice explaining the consumer's ability to opt out. (Note: This amendment does not alter 
the NACHA Operating Rules regarding general notification requirements for ARC entries. Originators must 
continue to ensure that they provide clear and conspicuous notice to the Receiver that states that the receipt 
of the Receiver's source document will authorize an ACH debit entry to the Receiver's account, in 
accordance with the terms of the source document.) 

ODFIs/RDFIs 

This amendment had no direct impact on ODFIs or RDFIs. 

ACH Operators 

This amendment had no impact on ACH Operators. 

Software Changes for ACH Operators: None. 

Software Changes for Participating Depository Financial Institutions: None. 

Implementation Date: June 1 1, 2004 

(See also pages OR 3.) 
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INTERNET ISSUES 



Summary: 

Effective March 18, 2005, the NACHA Operating Rules will be modified to (1) establish a new ODFI 
warranty with respect to WEB entries that specifically relates to an Originator's obligation to use 
commercially reasonable methods of authentication to verify the Receiver's identity, and (2) uniquely 
identify this authentication requirement under the Originator's obligations with respect to WEB entries. 

Currently, the use of such verification procedures is implied, rather than explicitly stated, under the 
requirement that Originators employ commercially reasonable fraudulent transaction detection systems for 
WEB entries. With the growth of WEB entries, it has become evident from the volume of unauthorized 
transactions that Originators of WEB entries do not have a clear understanding that the use of various fraud- 
prevention measures to identify potential fraudulent debit activity must also include the use of commercially 
reasonable procedures to verify the identity of the Receiver. The clarifications included in this proposal will 
draw attention to the importance of verifying the identity of Receivers of ACH entries authorized over the 
Internet. 

In addition, this amendment will make corrections to the listings of the parties affected by the new data 
security requirements governing the use of 128-bit RC4 encryption technology for ACH entries involving 
banking information that is transmitted or exchanged via an Unsecured Electronic Network. These changes 
clarify certain sections of the rule provisions that currently contain incomplete listings of the parties between 
which the transmission of such information must be encrypted. Corresponding updates to the Rules 
Compliance Audit Requirements are included within this amendment. 

This rule amendment also incorporates minor revisions to clarify rules language with respect to the 
Receiver's authorization for ACH transactions. The proposed modifications simply rearrange existing 
wording without any changes to its substance. 

Background 

The NACHA Operating Rules require Originators of WEB entries to obtain the consumer's authorization for 
this debit application. The Rules require that the authorization (1) be in writing and signed or similarly 
authenticated by the Receiver, (2) be readily identifiable as an ACH debit authorization, (3) clearly and 
conspicuously state its terms, and (4) for recurring payments only, provide the Receiver with a method to 
revoke their authorization by notifying the Originator in the manner prescribed. 

To meet the requirement that the authorization be in writing, in the context of WEB entries, this means that 
the consumer must be able to read the authorization language displayed on a computer screen or other visual 
display. The Originator should prompt the consumer to print the authorization and retain a copy. The 
Originator must be able to provide the consumer with a hard copy of the authorization if requested to do so. 

The Rules include the use of a digital signature or code to similarly authenticate a written authorization. This 
does not exclude other methods of similarly authenticating an authorization, such as a shared secret, etc. To 
satisfy the requirements of the Rules, the authentication method chosen must not only identify the consumer 
but also must demonstrate the consumer's assent to the authorization. The Federal Reserve Board, in its 
Official Staff Commentary to Regulation E, clarified that the similarly authenticated standard permits signed, 
written authorizations to be provided electronically, and that such writing and signature requirements are 
satisfied by compliance with the Electronic Signatures in Global and National Commerce Act (15 U.S.C. 
7001 et seq.), which defines electronic records and electronic signatures. Electronic signatures include, but 
are not limited to, digital signatures and security codes. 
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The Rules require that each Originator of WEB entries employ a commercially reasonable fraudulent 
transaction detection system to screen each entry. The NA CHA Operating Guidelines include the 
interpretation that fraudulent transaction detection systems contain a method of authentication to identify the 
Receiver.;/-. 

The existing requirement within the Rules to apply fraudulent transaction detection systems to WEB entries 
was designed with the intent of including, among other fraud-prevention measures, the requirement for 
Originators to authenticate the Receiver ' s identity . The NA CHA Operating Guidelines address this and other 
such obligations within the discussion of fraudulent transaction detection systems. However, it has become 
clear that the distinction between verifying the Receiver's identity and the identification of fraudulent debit 
activity through additional fraud-prevention capabilities is not a 
entries.; ■.■■' 

With respect to the new rule provisions (effective September 10, 2004) that relate to 
requirements for ACH entries involving banking information transmitted or exchanged via an Unsecured 
Electronic Network, certain sections of the new rule provisions contain incomplete listings of the parties 
between which the transmission of such information must be encrypted. This rule amendment clarifies the 
various parties between which the exchange of information over an Unsecured Electronic Network must be 
encrypted. 

Impact to Participants 

■ Originators 

This amendment will clarify the Originator '■ s specific obligation, with respect to WEB entries, to employ 
commercially reasonable methods of authentication to verify the identity of the Receiver. Orig^^ 
are not currently in compliance with the NA CHA Operating Rides related to this requirement will need to 
make modifications to their authentication procedures and practices. 

ODFIs 

The addition of specific rules and a new ODFI warranty related to the use of commercially reasonable 
methods of authentication to verify the Receiver's identity with respect to WEB entries will provide 
clarification for both Originator and ODFI that such risk management obligations are critical in helping to 
mitigate fraud in the ACH Network. In the current 

the Originator's requirements related to authenticating the Receiver's identity for WEB entries and x^ 
be properly educating their Originators. ODFIs will need to be aware of this new warranty and to ensure that 
it is addressed appropriately within their ODFI/Originator agreements. ODFIs should also work closely with 
their Originators to ensure that they are in compliance with the requirements of the R ules with respect to the 
use of commercially reasonable methods of authentication to verify the Receiver's identity for WEB entries. 

ACH Operators 

This rule amendment will have no impact on ACH Operators. 

This amendment will have no operational impact on RDFIs; however, RDFIs should benefit from a reduction 
in the number of unauthorized WEB entries entered into the ACH Network. 
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SOFTWARE CHANGES FOR ACHO^ 

Software Changes for Participating Depository Financial Institutions: None 
Implementation Date: March 18,2005 
(See also pages OR 3, 5, 11113,15, 136, 138.) 
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RETURN ISSUES - ACH OPERATOR REQUIREMENTS 



Summary: 



On September 10, 2004, an amendment to the NACHA Operating Rules became effective that modified the 
Rules to resolve two inconsistencies between the ACH Operators' current practices related to return entries 
and the requirements of the Rules. Specifically, these changes, which largely impacted only the ACH 
Operators, (1) removed the ACH Operator mandatory field error edit on the Original Receiving DFI 
Identification Field within the addenda records of dishonored return and contested dishonored return entries 
since this field is defined as a required, rather than mandatory, field, and (2) established a requirement within 
the Rules that prohibits ACH Operators from settling return entries prior to the effective entry date in the 
Company/Batch Header record of the original entry, as reflected in the return Entry Detail Record. 

Clarification on Edit for Original Receiving DFI Identifica tion Field 

This amendment was developed in order to correct an inconsistency in the Rules related to the Original 
Receiving DFI Identification Field in the addenda records for returns. Software edits performed by ACH 
Operators on ACH transactions are defined within Appendix Three (Specifications for Data Acceptance) of 
the NACHA Operating Rules. Under the NACHA Operating Rules, the addenda records for return, 
dishonored return and contested dishonored return entries contain a field entitled "Original Receiving DFI 
Identification" (positions 28-35), which bears the routing number of the RDFI receiving the original entry. 
Although this field is defined within Appendix Two (ACH Record Format Specifications) as a required field 
(that is the ACH Operator does not edit the content of the field except to ensure that the field contains valid 
characters), the edit criteria under Return Reason Code R26 (Mandatory Field Error) within Appendix Three 
(Specifications for Data Acceptance) had defined this field as a mandatory field, requiring ACH Operators 
to reject such an entry if the content of the field is non-numeric. These 

inconsistency within the Rules. 

This amendment removed the reference to the ACH Operator edit on the original RDFI routing number 
within the addenda records of dishonored returns and contested dishonored returns, as previously required 
by the eleventh bullet of Return Reason Code R26 (Mandatory Field Error) in Section 3.6 of Appendix 
Three. Because this field is classified as a required field, ACH Operators do not edit this field for any 
specific content. 

Return Entry Settlement 

Under the previous description of the Settlement Date Field within Appendix Two, the NACHA Operating 
Rules required ACH Operators to settle return entries at the earliest opportunity (i.e., the same banking day 
of processing or the next banking day following the processing date). In certain situations, it was possible 
for a return entry to be settled by the ACH Operator before the original entry is settled. This could occur, 
for example, when an ODFI transmits a credit file on Monday for settlement on Wednesday. In some cases, 
such as with a closed account or an invalid account number, an RDFI may return the credit immediately 
(rather than waiting until after settlement of the original entry) and receive credit for the return on Monday 
or Tuesday. In this instance, the ODFI received credit for the return before it has been debited on Wednesday 
for the original entry, creating float with the ACH Network. 

This amendment eliminated the potential for float in the ACH Network by ensuring that ACH Operators do 
not settle return entries before the original entry has been settled. Specifically, this amendment modified the 
NACHA Operating Rules to prohibit ACH Operators from settling return entries prior to the effective entry 
date contained within the original entry, as it is reflected within the return entry. In the event that an 
effective entry date is stale or invalid, the ACH Operators will continue to settle the return entry at the 
earliest opportunity (i.e., same banking day of processing or next banking day following the processing date). 
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Impact To Participants 

ACH Operators 

ACH Operators were required to modify their software to remove any edit they might have had in place to 
ensure that the contents of the Original Receiving DFI Identification Field within dishonored returns and 
contested dishonored returns are numeric. ACH Operators were also required to modify their settlement 
practices to ensure that return entries are not settled prior to the effective entry date of the original entry, as 
reflected in the return entry. In any case in which the effective entry date on the original entry is stale or 
invalid, ACH Operators will continue to settle the entry at the earliest opportunity. 

ODFIs/RDFIs 

This rule amendment had little or no effect on ODFIs and RDFIs. DFIs should, however, be aware that they 
are not able to rely on an ACH Operator edit of the Original Receiving DFI Identification Field in dishonored 
and contested dishonored returns to ensure that it is numeric. ODFIs and RDFIs should be aware that ACH 
Operators are prohibited from settling return entries prior to the effective entry date in the original entry, as 
reflected in the return entry. As a result, the processing of and settlement for return entries may not occur 
at the same time: ODFIs and RDFIs may need to adjust their reports and procedures, as necessary, to 
accommodate this change. 

Originators 

There should have been no impact on Originators due to this rule amendment. 

Software Changes for ACH Operators: ACH Operators were required to modify their software to 
remove any edit they might have had in place to ensure that the contents of the Original Receiving DFI 
Identification Field within di shonored returns and contested dishonored returns are numeric . ACH Operators 
were also required to modify their software to ensure that return entries are not settled prior to the effective 
entry date of the original entry, as reflected in the return entry. In any case in which the effective entry date 
on the original entry is stale or invalid, ACH Operators will continue to settle the entry at the earliest 
■ opportunity. :':'■■■'.■;'■.■'■'■ 

Software Changes for Participating Depository Financial Institutions: None 

Implementation Date: September 1 0, 2004 

(See also pages OR 82, 88.) 
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RETURNS FOR UNAUTHORIZED DEBITS TO CONSUMER ACCOUNTS 
USING A CORPORATE SEC CODE 

Summary: 

Effective March 18, 2005, the NACHA Operating Rules will be amended to reactivate Return Reason Code 
R05 to accommodate the return of unauthorized debit entries to consumer accounts when those debits were 
transmitted using a corporate Standard Entry Class Code (i.e., CCD, CTX, and CBR). This rule change will 
enable RDFIs to apply the same return rules and time frames (i.e., 60 days from Settlement Date) for 
returning all unauthorized debits to consumer accounts, regardless of the SEC Code contained within the 
entry. 

Background 

Consumer debit entries returned by the RDFI as unauthorized will bear Return Reason Code RIO (Customer 
Advises Not Authorized, Notice Not Provided, Improper Source Document, or Amount of Entry Not 
Accurately Obtained from Source Document) and must be returned by the RDFI by its ACH Operator's 
deposit deadline for the return to be made available to the ODFI no later than the opening of business on the 
banking day following the sixtieth calendar day following the Settlement Date of the original entry. 

At times, Originators may erroneously transmit ACH entries that are formatted using an incorrect SEC Code. 

This is in violation of the NACHA Operating Rules. Because the Rules require the RDFI to rely on the 

ODFF s warranty that the SEC Code included in the entry is proper, the RDFI is obligated to use the return 

rules and time frames associated with that particular SEC Code. Currently, an u^ 

consumer account where that entry incorrectly bears a corporate SEC Code must be returned in accordance 

with the return rules and time frames governing corporate transactions (that is, using Return Reason Code 

R29 within two banking days of the Settlement Date of the original en^ 

typically precluded from automatically returning such an unauthorized debit because the return time frame 

for corporate entries will have lapsed before the consumer can receive his statement and notify his RDF^ 

about the unauthorized debit to his account. Instead, the RDFI would be required to request permission from 

the ODFI to return the entry as a permissible return. 

Effective March 1 8, 2005 , a new Return Reason Code R05 (Unauthorized Debit to Consumer Account Using 
Corporate SEC Code) will become available to RDFIs for the return of unauthorized debits transmitted to 
consumer accounts when those debit entries incorrectly bear a corporate SEC Code (i.e., CCD, CTX, or 
CBR). With the addition of this rule, the RDFI will be permitted to return all unauthorized debits to consumer 
accounts, regardless of SEC Code, within sixty days of the Settlement Date of the original entry, provided 
the RDFI has obtained a written statement under penalty of perjury from the consumer. 

Impact to Participants: . ... 

Originators 

Originators should be aware that, as of March 18, 2005, they may receive certain CCD, CTX, and CBR 
entries returned using Return Reason Code R05 (Unauthorized Debit to Consumer Account Using Corporate 
SEC Code) for up to sixty days from the Settlement Date of the original entry. Originators will need to 
ensure that their internal practices and software packages are modified to recognize and accommodate the 
use of this return reason code. Originators should be aware that, for any entry returned using Return Reason 
Code R05, the RDFI warrants that it has obtained a written statement under penalty of perjury from the 
Receiver in which the Receiver claims the entry is not authorized. Originators may request copies of such 
written statements through their ODFIs. 
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It is important that Originators understand the proper use of SEC Codes when originating transactions into 
the ACH Network. Originators should ensure that they have procedures in place to properly identify the type 
of account (i.e., consumer or corporate) to which an ACH entry is directed and to apply the appropriate 
Standard Entry Class Code to the entry. 

ODFIs 

ODFIs will need to be aware that, as of March 18, 2005, they may receive certain CCD, CTX, and CBR 
entries bearing Return Reason Code R05 for up to sixty days from settlement date. ODFIs will need to 
modify their ACH software to accommodate the receipt of return entries bearing this Return Reason Code. 
ODFIs should be aware that RDFIs will be required to warrant that written statements under penalty of 
perjury have been obtained for each CCD, CTX, or CBR entry returned using this code. ODFIs should also 
be aware that their Originators may request that the ODFI obtain copies of such written statements from the 
RDFL 

RDFIs 

RDFIs should be aware that, as of March 18, 2005, they will be permitted to return an unauthorized CCD, 
CTX, or CBR debit that is transmitted to a consumer account for up to sixty days from the Settlement Date 
of the original entry. Specifically, the RDFI will be required to transmit the return of such an entry by its 
ACH Operator's deposit deadline for the return entry to be made available to the ODFI no later than the 
opening of business on the banking day following the sixtieth calendar day following the Settlement Date 
of the original entry. RDFIs will need to modify their ACH software to accommodate the transmission of 
entries using this Return Reason Code. RDFIs will also need to ensure that they have established procedures 
to obtain the consumer's written statement under penalty of perjury for each such entry. This amendment 
will enable the RDFI to return all unauthorized entries to consumer accounts in the same manner and within 
the same time frame, eliminating the need for special handling of unauthorized entries that have been 
improperly coded by the Originator. 

ACH Operators 

ACH Operators will need modify their ACH software to accommodate the revisions to the descriptions and 
uses of Return Reason Code R05. 

Software Changes for ACH Operators: ACH Operators will need to modify their software to 
accommodate the revised usage of Return Reason Code R05. 

Software Changes for Participating DFIs: ODFIs and RDFIs will need to modify their ACH 

software to accommodate the transmission and receipt of return entries bearing Return Reason Code R05. 

Implementation Date: March 18, 2005 

(See also pages OR 23, 24, 25, 90.) 
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THIRD-PARTY SERVICE PROVIDER ISSUES 



Summary:. : : . 

OnDecember 10,2004, an amendment to ^ 

provisions of the A^C^ 

certain types of Third-P^ as "Third-Party Senders") that act as 

intermediaries between an Originator and an ODFI. 

The Rules require that an Originator and an ODFI have an agreement that, among other m^ 
Originator to the Rules . However, it is common practice among some Originators and ODFIs to have 
agreements with a Third-Party Service Provider that stands between the Originator and the ODFI and acts in 
an intermediary capacity between these two parties. In such circumstances, the lack of a direct contractual 
relationship between the Originator and the ODFI has the potential to increase the risk incurred by the ODFI 
since it may be unable to establish a claim against the Originator in the event of loss. This amendment 
established an appropriate legal framework within the i?wfe to accommodate tM 
Originator-Third-Party Service Provider-OPFI^ 
bound to the Rules and that the Third-Party Send^^ 

Specifically, the Rules were modified to explicitly required 

into a contractual agreement under which the Originator agrees to be bound by the ^A^ 

(as is currently required by the NACHA Operating Rules), or (2) any Third-Party Sender has entered mto 

appropriate agreements (i.e., between the ODFI and Third-Party Sender, between the Third-Party Sender and 

the Originator, and between the Third-Party Sender and any other Third-Party Senders) under which the 

Third-Party Sender is bound by these mles as in effect from time to time and acto 

not be initiated that violate the laws of the United States, and the Originator has assumed the responsibilities 

of an Originator under these rules and has acknowledged that entries may not be initiated that violate the laws 

of the United States. Each Third-Party Sender is subject to the requirements of Article Five (Obligations of 

Third-Party Senders.) 

In any case where an Originator has an agreement with a Third-Party Sender rather than an ODFI to 
originate ACH entries into the Network, (1) the Third-Party Sender must enter into an agreement 
(either with an ODFI or another Third-Party Sender) under which the Third-Party Sender 

by the NA'CHA'fy^ 

Party Sender under which the Originator assume$ the responsibilities of an Originator under the 
NACHA Operating Rules. These agreements must include an acknowledgment that entries may not 
be initiated that violate the laws of the United St^^ 

• Each Third-Party Sender is subject to the requirements of Article Five (Obligations of Third-Party 

Senders), which specifically address obligations of Third-Party Senders. 

-- Identification of Originators; 

- Warranty and Indemnification of Third-Party Sender; 

- Assumption of ODFI Warranties; 

- Payment to ODFI; 

— Assumption of ODFI Responsibilities; and 

■.'.'■'■ 'V.' - Assumption of Originator Responsibilities. 

An ODFI must (1 ) establish an exposure limit for either the Originator or the Third-Party Sender from 
which it receives entries, (2) implement procedures to review that exposure limit periodically, (3) 
implement procedures to monitor entries initiated by either the Originator or Third-Party Sender, 
relative to its exposure limit, across multiple settlement dates, and (4) implement procedures to 
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monitor the payments system risk associated with GBR and PBR entries initiated by either the 
Originator or Third-Party Sender. 

An ODFI's warranties regarding revocation of authorization have been expanded to require ODFIs 
to warrant that; when a Third-Party Sender is involved 

agreements as required by Article Two, subsection 2 . 1 .1 have not been terminated and that the Third- 
Party Sender has no knowledge of the revocation of the Receiver's authorization or of the termination 
of the arrangement between the RDFI and the Receiver concerning the entry. 

■'.•'■;■■ T^ 

require GDFIs to warrant that Third-Party Senders (1) establish procedures to monitor, on an on-going 

basis, the credit-worthiness of any Originator or Third-Party Sender fr^ 

entries, (2) establish exposure limits for the Originator or Third-Party Sender from which it receives 

WEB entries; (3) implement procedures to review exposure limits for WEB entries periodically, and 

(4) implement procedures to monitor entries sent or fransinitted by the Originator 

Senders relative to their exposure limits across multiple settlement dates. 

• Originators that utilize the services of Third-Party Senders to authorize an ODFI to transmit entries 

on behalf of an Originator must agree to make payment to the ODFI for any credit entries originated 
and for any debit entries returned by the RDFI when the ODFI does not receive payment from the 
Third-Party Sender. 

Article Eleven (Gross-Border Payments), section 11.2 (Originator/ODFI Agreement) was modified 
to require a Third-Party Sender involved in the origination of outbound CBR/PBR entries to specify 
in the agreement required by subsection 2. 1 .2 (1) the terms and conditions for the allocation of gains, 
losses, and the assumption of risk for foreign exchange conversion, and (2) the rights and 
responsibilities of the ODFI in the event of error or duplicate entries. 

The definition of "Originator" was clarified and a new definition of "Third-Party Sender" was added 
to the definition of terms to clearly distinguish between these AGH participants. 

The ODFI's audit requirements were expanded to require the ODFI to conduct an examination of 
ACE[ operations and review procedures related to the origination of entries in circumstances where 
a Third-Party Sender is acting on behalf of the Originator with respect to the origination of entries. 

Background 

This amendment was developed in order to establish a sound legal framework within the NA CHA Operating 
Rules to support a widely-used business practice in which some Originators do not have agreements directly 
with the ODFI. Rather, a Third-Party Service Provider may have an agreement with an Originator to deliver 
the Originator ' s entries to the ODFI. The Third-Party Service Provider also has an agreement with an ODFI 
to deliver entries to the ODFI; however, there is no direct agreement belweeh the ODFI and the 
In these cases, the Third-Party Service Provider acts as an intermediary between an Originator and an ODFI, 
bypassing the requirement within the Rules that there be a contractual agreement between Originator and 
ODFI that binds the Originator to the Rules. TTiismle amendment modifi^ 
reflect and enable current business practice. 

Prior to the implementation of this amendment, Third-Party Service Providers were addressed only within a 
limited number of provisions of the NACHA Operating Rules. A brief description of those sections of the 
Rules follows: 
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•■':■ Definition of Third-Party Service Provider: A Third-Party Service Provider is defined in the 

NACHA Operating Rules as: 

"...an entity other than an Originator, ODFI or RDFI that perfbmi^ 

Originator, ODFI or RDFI related to AGH processing of entries, including but not limited t^ 

creation of ACH files or acting as a Sending or ReceivingPointonbehalf of a Participating DFI." 

ODFI Agreement with Sending Point: Certain provisions of the Rules (Article Two, Subsections 
2.2. 1. 1 1 and 2.2.4) require an ODFI to warrant that it has a contractual agreement with a Third-Party 
Service Provider that acts as a Sending Point on behalf of the 
have made all warranties defined by tte 

regardless of whether the Sending Point was authorized by the ODFI to to 

Point is a person that transmits entries to an ACHOperator on behalf of an ODFI. A Sending Point 
may be an ODFI acting on its own behalf, or a Participating DFI, a commercial data processm^ 
service organization, or a person operating a data transmission facility, acting on behalf of one or 
■'■■ moreODFIs. '. 

> R^ 

the Rules addresses Third-Party Service Providers that act as Receiving Points for RDFIs, stating that 
when an entry is made available by an AGH Operator to an RDFTs Receiving Point, it is deemed to 
be received by the RDFI. 

• Rules Compliance Audit Requirements: The audit requirements in the i?wte (Appendix Eight) 
require Third-Party Service Providers that perform any fonctions of AGH processing o^ 

ODFI or RDFI to complete an annual rules compliance audit. 

National System of Fines: The National System of the Rules) includes 

a provision that a rule violation can be counted against a Third-Party Service Provider that is allegedly 
responsible for the rule violation. 

Additionally, some ODFI obligations under the NACHA Operating Rules in relation to Originators are 
particularly relevant to the discussion of Third-Parly Service Providers. 

Proper Authorkation: Among numerous other warranties, the ODFI is responsible for ensuring that 
its Originators obtain proper authorization for each entry in accordance with the NACHA Operating 
■ ■ Rules.- ; 

• ODFI-Originator Agreements: The NACHA Operating Rules reqvw 
agreement with each Originator that binds tlie Originator to^ 

The Role of TM^ 

As the AGH Network has evolved, Third-Party Service Providers have taken on larger and more complex roles 
in the processing of ACH transactions. To properly understand the impact of rule provisions on Third-Party 
Service Providers, it is essential to have a clear understanding of the specific roles Thirds 
Providers play in the ACH Network and to understand clearly the distinction between a Third-Party Sem 
Provider and an Originator. 

■ :■• Originator 

The definition of an Originator clearly distinguishes between an Originator of an ACH entry or file and a 
Third-Party Service Provider to whom some portion of the Originator's ACH processing requirements are 
outsourced. For purposes of the Rules, an Originator is defined as: 
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(1) an entity that has authorized an ODFI to send or transmit, for the account of that person, (i) a credit 
entry to the account of a Receiver with an RDFI to effect a payment from that person to the Receiver, 
or (ii) a debit entry to the Receiver's transaction account or general ledger account with an RDFI in 
order to effect a payment from the Receiver to that person; or 

(2) an entity that has authorized a Third-Party Sender to send or transmit to an ODFI for the account of 
that, or another, Third-Party Sender (i) a credit entry to the account of a Receiver with an RDFI in 
order to effect a payment from that person to the Receiver, or (ii) a debit entry to the Receiver's 
transaction account or general ledger account with an RDFI in order to effect a payment from the 
Receiver to that person. 

The Originator is the party with whom the Receiver has a contractual relationship and to or from whom 
funds are ultimately owed. In some situations, the Originator may enter into a contractual agreement with 
a Third-Party Service Provider, such as a payroll processor or other type of service provider, to process the 
company's payments where the Third-Party Service Provider, rather than the ultimate Originator of the 
payments, has the contractual relationship with the ODFI and against whose account funds are settled. 
While this business model is commonplace in today's payments environment, it is important that ACH 
participants recognize that the Third-Party Service Provider is not the Originator of the transactions. 

• Third-Party Service Provider 

A Third-Party Service Provider is an entity other than an Originator, ODFI, or RDFI that performs any 
functions on behalf of the Originator, the ODFI, or the RDFI with respect to the processing of ACH entries, 
including, but not limited to, the creation of ACH files. 

- Sending Point 

Third-Party Service Providers may act as Sending Points on behalf of a Participating DFI. A Sending 
Point is an entity that transmits entries to an ACH Operator on behalf of an ODFI. A Sending Point 
may be an ODFI acting on its own behalf, or a Participating DFI, a commercial data processing 
service organization, or a person operating a data transmission facility that acts on behalf of one or 
more ODFIs. (NOTE: The NACHA Operating Rules require an agreement between the ODFI and the 
Sending Point when a Sending Point is used by the ODFI to transmit ACH entries to the ACH 
Operator on its behalf.) 

- Receiving Point 

Third-Party Service Providers may also act Receiving Points on behalf of a Participating DFL A 
Receiving Point is an entity that receives entries from an ACH Operator on behalf of an RDFI. A 
Receiving Point may be an RDFI acting on its own behalf, a Participating DFI, a commercial data 
processing service organization, or a person operating a data transmission facility that acts on behalf 
of one or more RDFIs. 

• Third-Party Sender 

A Third-Party Sender is a Third-Party Service Provider that is not an Originator and that has authorized an 
ODFI or another Third-Party Sender to fransmit, for the account of the Third-Pa^ 
Party Sender, (i) a credit entry to the account of a Receiver with an RDFI in order to effect a payment 
the Originator to the Receiver, or (ii) a debit entry to the Receiver's transaction account or general ledger 
account with an RDFI in order to effect a payment from the Receiver to the Originator. 

Third-Party Senders are a subset of Third-Party Service Providers. That is, a Third-Party Sender is always 
a Third-Party Service Provider that acts on behalf of an Originator y but a Third-Party Service Provider does 
not always act as a Third-Party Sender. A Third-Party Service Provider is considered to be a Third-Party 
Sender when it acts as an intermediary between the ODFI and the Originator and there is no contractual 
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agreement between the Originator and the ODFL In any circumstance in which an Originator utilizes the 
services of a Third-Party Service Provider but has also executed a contract*^ 
ODFI, the Third-Party Service Provider would ngl be considered a Thirds 
subject to the rule provisions governing Third-Party Senders. 

Examples of Third-Party Service Provider/Third-Partv Sender Relationships 

The following examples are provided to help clarify the specific circumstances in which a Third-Party Service 
Provider is also considered to be a Third-Party Sender. 

Example # 1 

An employer contracts with ABC Payroll to handle its payroll processing. ABC Pay^ 

agreement with its own financial institution, MegaBank, to originate ACH activity on its behalf, and ABC 

Payroll's account at MegaBank is credited or debited by MegaBank for settlement of to 

processed by ABC Payroll. In this example, there is no relationship between^ to 

and they do not have a contractual agreement between them for to origination payments. Instead, 

ABC Payroll is an intermediary between the employer and MegaBank. 

It is important to recognize that the employer in this example is the Originator of the payroll file because it 
is legally obligated to pay its employees, the Receivers. ABC Payroll is a Third-Party Service Provider 
performing the function of creating the payroll file on behalf of the Originator and transmitting it to the ODFL 
In this scenario, ABC Payroll is also a Third-Party Sender because it is acting as an intermediary between the 
employer (the Originator) and MegaBank (the ODFI) and no contractual agreement exists between the ODFI 
and the Originator. 

Example # 2 

An employer contracts with ABC Payroll to handle its payroll processing. ABC Payroll formats the ACH file 

on behalf of the employer and forwards it on to MegaBank, wit^ 

agreement to originate ACH activity on its behalf In this case, the employer holds an account with MegaBank 

that is credited or debited by MegaBank for settle 

on the employer's behalf 

The employer in this example is the Originator of the payroll file because it is legally obligated to pay its 
employees, the Receivers. ABC Payroll is a Third-Party Service Provider performing the function of creating 
the payroll file on behalf of the Originator and trans 

Payroll is not a Third-Party Sender because a direct contractual agreement exists between the ODFI and to 
Originator that binds the employer to ih^NACHA Operating Rules: 

Example #3 

An employer contracts with ABC Payroll to handle its payroll processing. ABC Payroll has further contracted 
with ACH Pay Service Provider for the origination of its ACH processing into the ACH Network. ACH Pay 
Service Provider has a contractual agreement with its own financial institution, MegaBank, to originate ACH 
activity on its behalf; and ACH Pay Service Provider's account at MegaBank is credited or debited by 
MegaBank for the settlement of transactions processed by ACH Pay Service Provide^ 
is no relationship between to employer and Meg 

between them for the origination of ACH payments. Similarly, there is no contracUial agreement te 
ABC Payroll and MegaBank for the origination of ACH payments, hi this case, there are two intermediaries 
(ABC Payroll and ACH Pay Service Provider) between the employer and MegaBank. 

The employer in this example is the Originator of the payrolffilebecause it is legally obligated 
employees, the Receivers. ABC Payroll and ACH Pay Service Provider are both Third-Party Service Providers 
acting as Third-Party Senders because they are acting as intermediaries between the employer (the Originator) 
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and MegaBank (the ODFI) and no contractual agreement exists between the ODFI and the Originator. In this 
case, AGH Pay Service Provider would have an agreement with the ODFI(MegaBank) under which AGH Pay 
Service Provider agrees to be bound to the NACHA Operating Rules, and ABC Payroll would have agreements 
with both the Originator (the employer) and the other Third-Party Sender (AGH Pay Service Provider), under 
which both ABC Payroll and the employer agree to be bound to the Rules. 

Impact to Participants: 

Originators ;-v/-^\v";; ^'■V■■:;V/.\'■;.;;V■■^ : /"v^■v;/;;^'■ : ■:^V^^^/■ 

Only certain Originators are impacted by this amendment. If an Originator has a direct agreement with an 
ODFI, the Originator is unaffected by these changes. However; an the services of a 

Third-Party Sender must review its contractual agreement with the Third-Party Sender to ensure that it meets 
the requirements of the rule and to ensure that it has assumed the responsibilities of an Originator under the 
NACHA Operating Rules. It is recommended that this agreement also address the specific responsibilities of 
both the Originator and the Third-Party Sender with respect to warranties and liabilities; the quality of the 
data, input schedules, processing deadlines, and other issues relevant to the processing and delivery of entries 
and entry information. Originators should know the credit worthiness of these Third-Party Senders because 
they could be responsible to the ODFI for payments if the Third-Party Sender should fail. 

ODFIs 

ODFIs benefit from this rule amendment because it helps to protect them from the risks (credit risk in 
particular) inherent to business relationships established with Third-Party Service Providers where those Third 
Parties act as the intermediary between the ODFI and the ultimate Originator. Under the previous m 
framework, if the ODFI and the Originator did not have an agreement that binds the Originator to the NACHA 
Operating Rules, the ODFI was exposed to additional credit risk. This is because the ^O^ 
responsible for all transactions that it originates. In the case of debit entries, it was unlikely that the ODFI 
would be able to seek recourse or restitution from the tme Originator of the transaction if th^ 
Originator had no contractual agreement and the TTiird-PartySemce Provider with which te 
relationship did not make the ODFI whole for any reliirned transactions. With respect to 
ODFI did not have a way to seek recourse against the ultimate Originator in the event of the Third-Party 
Service Provider's failure to fund the transactions. 

Third-Party Sender relationships also create an environment in which the ODFI is not able to ensure that it 
knows the entity truly originating the payments or its underlying business practices. However, such knowledge 
by the ODFI is essential so that the ODFI can make pmdent decisions as to whether it wants 
origination services for the lines of business undertaken by such Originators and to assume the risk associated 
with those types of transactions. An ODFI with a thorough knowledge of its Originators and their business 
activities is far more likely to be capable of making an informed credit decision and to be aware of any 
potential problems with those Originators. 

Beyond risk management, this rule amendment also provides a framework within the Rules for ODFIs to 
expand their business relationships with Third-Party Senders. Since the Rules now clearly define this business 
model, ODFIs should be more comfortable looking for ways to utilize Third-Party Senders to expand their 
business opportunities. 

ODFIs may incur an expense in reviewing their current contracts with Third-Party Senders to ensure that the 
contracts address the additional requirements of this amendment. However, despite these expenses, ODFIs 
ultimately benefit from the protection provided by the Third-Party Sender, which assumes certain key 
responsibilities of an ODFI when the Third-Party Sender is processing ACH entries. 

Since the ODFF s relationship may be with the Third-Party Sender rather than the Originator, the ODFI will 
have to conduct an annual audit of rules compliance on the Third-Party Sender, set exposure limits on the 
Third-Party Sender (or the Originator, at the ODFFs option), and warrant that the Third-Party Sender (as 
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opposed to the Originator) has followed relevant WE 

that the agreement between a Third-Party Sender and an Originator has not been terminated and that the Third- 
Party Sender has no knowledge of the revocation of the Receiver's authorization or tte 
arrangement between the RDFI and the Receiver concerning the entry. 

RDFIs ,■■;'■.'.';■' 

This rule amendment had no operational impact on RDFIs since this proposal relates to Third-Party Service 
Providers that perform a function on the origination side of an ACH transaction. By clarifying the rules 
framework with respect to the origination of entries, this rule amendment also had a positive impact on RDFIs 
by helping to ensure that transactions are properly authorized and that ODFIs are aware of the businesses for 
which they are originating transactions. These improvements to the origination process will afford more 
protection and minimize the risk to the RDFI. 

ACH Operators 

This rule amendment had no operational impact on ACH Operators. 

Third-Party Service Providers 

This rule amendment clarifies and recognizes the role of Third-Party Senders in the origination of ACH 
transactions and establishes the legal framework to enable the current industry practice in which Third-Party 
Senders act as intermediaries between Originators and ODFIs. 

If such an agreement does not already exist, each Third-Party Service Provider that acts as a Third-Party 
Sender must enter into a contractual agreement with either an ODFI or another Third-Party Sender under 
which the Third-Party Sender agrees to be bound by the NACHA Operating Rules. 

Third-Party Senders, along with their Originators, are obligated to agree to make payment to the ODFI for any 
credit entries originated and for any debit entries returned by the RDFI. Third-Party Senders must ensure that 
they have established policies and procedures in order to be able to provide the ODFI, upon its request, any 
information that the ODFI deems necessary to identify each Originator for which it processes. 

Third-Party Senders assume a number of specific warranties and responsibilities of the ODFI, in addition to 
specific responsibilities of the Originator, when originating entries on behalf of Originators. 

This rule amendment has no impact on Third-Party Service Providers that are not acting as Third Party 
Senders. Third-Party Service Providers are not impacted by this proposed rule in any case where the 
Originator and the ODFI have a contractual agreement directly between them for the origination of ACH 
transactions. 

Software Changes for ACH Operators: None. 

Software Changes for Participating Depository Financial Institutions: None. 

Implementation Date: December 10, 2004 

(See also pages OR 2, 4, 5, 11,15,18, 19, 29,35,37,137.) 



R 20 



OPERATING RULES 



OF THE 



NATIONAL AUTOMATED CLEARING HOUSE ASSOCIATION 



2005 OPERATING RULES 



TABLE OF CONTENTS 



OPERATING RULES OF THE 

NATIONAL AUTOMATED CLEARING HOUSE ASSOCIATION 



TABLE OF CONTENTS 



PREFACE 

NACHA BOARD OF DIRECTORS POLICY STATEMENT ON 
DATA SECURITY 

NACHA BOARD OF DIRECTORS POLICY STATEMENT ON 
ELECTRONIC TRANSMISSION BETWEEN ORIGINATORS AND ODFIS 

NACHA BOARD OF DIRECTORS POLICY STATEMENT ON 
FRAUD PREVENTION AND RISK MANAGEMENT INITIATIVES 



ARTICLE I - 


■■': GENERAL ^ 




1.1 


Application of Rules 




1.2 


Compliance with Rules 




V-3 


Excused Delay 




1.4 


Days on Which Institution or Facility is 
Closed 



1 .5 Transmission of ACH Information Via 
Unsecured Electronic Networks 

1.6 Records 

1.7 Choice of Law 



ORix 



ORxi 



ORxiii 



OR xv 



ORl 
ORl 
ORl 

OR1 

ORl 
ORl 
OR 2 



ARTICLED 



ORIGINATION OF ENTRIES 

2.1 Prerequisites to Origination 

2.2 Warranties and Liabilities of Originating 
Depository Financial Institutions 



2.3 


Prenotifications 


2.4 


Reversing Files 


2.5 


Reversing Entries 


2.6 


Reclamation Entries 


2.7 


Destroyed Check Entries 



OR2 

OR 4 
OR 6 
0R6 
OR7 
OR7 
OR 8 



ORi 



TABLE OF CONTENTS 



2005 OPERATING RULES 




ARTICLE III - 



2.8 Re-presented Check Entries 

2.9 Accounts Receivable Entries 

2 . 1 Internet-Initiated Entries 

2.11 Telephone-Initiated Entries 

2.12 Reinitiation of Returned Entries by Originators 

2.13 Media ahd Format Specification Requirements 

2.14 Release of Information 

OBLIGATIONS OF ORIGINATORS 

3.1 General 

3.2 MTE, POS, and SHR Entry PIN Requirements 

3.3 Transmission of ACH Information Via Unsecured 
Electronic Networks 

3.4 Consumer Accounts - Notice by Originator to 
Receiver of Variable Debits 

3.5 Consumer Accounts -Copy of Debit Authorization 
3 6 Obligations of Originators of RCK Entries 

3.7 Obligations of Originators of ARC Entries 
3 8 Obligations of Originators of POP Entries 

3.9 Obligations of Originators of Internet-Initiated 
Entries 

3.10 Obligations of Originators of Telephone-Initiated 
:'.'.■ Entries 

3.11 Payment to ODFI 

3.12 Record of Authorization 



OR 9 
ORIO 
OR 11 
OR 12 
OR 12 
OR 12 
OR 12 



OR 12 
OR 12 

OR 13 

OR 13 
OR 13 
OR 13 
OR 14 
OR14 

OR 15 

OR15 
OR 15 
OR 15 



ARTICLEIV- RECEIPT OF ENTRIES 

4. 1 General Rights and Obligations of RDFI 

4.2 Warranties of Receiving Depository 
Financial Institutions 

4.3 Receipt and Availability of Entries 



OR 16 

OR 16 
OR 16 



OR ii 



2005 OPERATING RULES 



TABLE OF CONTENTS 



ARTICLE V 



ARTICLE VI- 



ARTICLEVn 



4.4 

4.5 
4.6 
4.7 
4.8 
4.9 



Availability of Entries and Entry Information, 
Crediting and Debiting of Entries 

Periodic Statements 

Notice to Receiver 

Release of Information 

Liability of RDFI for Benefit Payments 

RDFI Receipt of Death Notification Entry 



OR 16 
OR 17 
OR 17 
OR 17 
OR 17 
OR 18 



OBLIGATIONS OF THIRD-PARTY SENDERS 

5.1 Identification of Originators 

Warranty and Indemnification of Third-Party Sender 
Assumption of ODFI Warranties 
Payment to ODFI 

Assumption of ODFI Responsibilities 
Assumption of Originator Responsibilities 




5.2 
5.3 
5.4 
5.5 
5.6 



OR 18 
ORIS 
OR 18 
OR 19 
OR 19 
OR 19 



RETURN, ADJUSTMENT, CORRECTION, AND 
ACKNOWLEDGMENT OF ENTRIES AND ENTRY INFORMATION 



6.1 
6.2 
6.3 
6.4 
6.5 



Return of Entries 
Dishonor of Return Entries 
Notification of Change 
Refused Notification of Change 
Acknowledgment Entries 



Or 19 

OR 20 
OR 20 
OR 21 

OR21 



SETTLEMENT AND ACCOUNTABILITY 

7.1 Maintenance of Reserve Bank Accounts 

7.2 Settlement 

7.3 Effect of Settlement 

7.4 Accountability for Entries 

7.5 Effect of RDFI Closing on Time of Settlement 



OR 21 
OR 21 
OR 21 
OR 21 
OR 21 



ORiii 



TABLE OF CONTENTS 



2005 OPERATING 'RULES 



7.6 Effect of ODFI Closing on Time of Settlement 



OR 22 



ARTICLE VIII - 



RECALL, STOP PAYMENT, RECREDIT, AND ADJUSTMENT 

8.1 Recall by ODFI or Originator 

8.2 ODFI Request for Return 

8.3 ODFI Agrees to Accept CCD or CTX Return 

8.4 Stop Payment Affecting Consumer Accounts 

8.5 Stop Payment Affecting Non-Consumer Accounts 

8.6 Receiver's Right to Recredit 

8 .7 Adjustment Entries 

8.8 Application to MTE and SHR Entries 



OR22 


OR 22 


OR 22 


OR 22 


OR 22 


OR 22 


OR 24 


OR 26 



ARTICLE IX 



OBLIGATIONS OF AUTOMATED CLEARING HOUSE 
OPERATORS 

9.1 Processing Obligation 

9.2 Automated Accounting Advices 

9.3 Return and Rejection by ACH Operator 

9.4 Originator Status Code R.eview 

9.5 Optional Services 

9.6 Non-Settled Entries 

9.7 Entries Originated to an RDFI that 
CannotSettle 

9:8 Entries Received from an ODFI that 
CannotSettle 

9.9 Record of Entries 

9.10 Requirement to Provide Information to 
National Association 



OR 27 
OR 27 
OR 27 
OR27 
OR 27 
OR 27 

OR 27 

OR 27 
OR 28 

OR 28 



ARTICLE X 



CHECK TRUNCATION ENTRIES 

10.1 Scope 

1 .2 Eligible Participants and Warranties 



OR 28 
OR 28 



OR iv ' 



2005 OPERATING RULES 



TABLE OF CONTENTS 



10.3 Return and Rejection by an ACH Operator 

10.4 Format Specifications for TRC or TRX Entries 

10.5 Application of Rules to TRC or TRX Entries 

10.6 ' Inconsistency Between Article Nine and 

Program Rules 



OR 28 
OR 28 
OR 28 

OR 29 



ARTICLE XI- 



CROSS-BORDER PAYMENTS 

11.1 Scope 

11.2 Originator/ODFI Agreement 

11.3 ODFI70GO Agreement 

1 1 .4 ODFI Warranties for Outbound Cross-Border Entries 

11.5 OGO Warranties for Outbound Cross-Border Entries 

11.6 RGO Warranties for Inbound Cross-Border Entries 

11.7 OGO/RGO as Participating DFI 

11.8 Dishonor of Return by ODFI 

11.9 Application of Rules to Cross-Border Entries 



OR 29 
OR 29 
OR 29 
OR 29 
OR 29 
OR 30 
OR 30 
OR 30 
OR 30 



ARTICLE XH - 



REQUIREMENTS OF ASSOCIATIONS 

12.1 Warranties of Associations 

1 2.2 Requirements to Provide Information to 
National Association 

12.3 Association Liability for Negligence and Willful 
Misconduct of Its ACH Operator 

12.4 Protection for the National Association from 
Frivolous Lawsuits 

12.5 ACH Operator Not Agent of Participating DFI 



OR 31 
OR 31 
OR 31 

OR 32 

OR 32 



ARTICLE XIII 



AMENDMENT OF THE RULES 

13.1 Procedures for Amendment of the Rules 

13.2 Temporary Adoption, Suspension, or Change 
of Implementation Date of Rules 



OR 32 



OR 32 



ORv 



TABLE OF CONTENTS 



2005 OPERATING RULES 



ARTICLE XIV - DEFINITION OF TERMS 

14. 1 Definitions As Used in These Rules 

14.2 Construction Rules 

THE APPENDICES - TECHNICAL SPECIFICATIONS 



OR 32 
OR 37 



APPENDIX I 



APPENDIX II 



APPENDIX III 



APPENDIX IV - 



APPENDIX V 



ACH FILE EXCHANGE SPECIFICATIONS 

1.1 Electronic Transmission Requirements 

1.2 ACH Tape Specifications 

1 .3 Data Specifications 

1.4 Sequence of Records in ACH Files 

1.5 File Structure 

1 .6 Trace Number Sequence in ACH Files 

ACH RECORD FORMAT SPECIFICATIONS 

2.1 Record Formats 

2.2 Code Values 

2.3 Glossary of File Format Data Elements 

SPECIFICATIONS FOR DATA ACCEPTANCE 

3.1 File Acknowledgment 

3.2 File Level Reject Option 

3.3 Batch Level Reject Option 

3.4 Automatic File Rejection 

3.5 Automatic Batch Rejection 

3.6 Automatic Entry Detail Return Entry 

MINIMUM DESCRIPTION STANDARDS 

RETURN ENTRIES 

5.1 Automated Return Entries 



OR 38 
OR 38 
OR 38 
OR 38 
OR 39 
OR 43 



OR 43 
OR 68 
OR 70 



OR 85 
OR 86 
OR 86 
OR 86 
OR 86 
OR 87 

OR 89 



OR 89 



ORvi 



2005 OPERATING RULES 



TABLE OF CONTENTS 



APPENDIX VI - 



5.2 Non-Automated Return Entries 
■5.3. Adjustment Entries 

5.4 Table of Return Reason Codes 

5.5 Record Formats for Automated and 
Converted Return Entries 

5.6 Dishonored ACH Return Entries 

5.7 Contested Dishonored ACH Return Entries 

NOTIFICATION OF CHANGE 

6.1 Automated Notification of Change 

Non- Automated Notification of Change 
Refused ACH Notification of Change 



6.2 
6.3 
6.4 



Minimum Description Standards for Notifications 
of Change and Corrected Notifications of Change 



6.5 Table of Change Codes 

6.6 Record Formats for Automated and Converted 
Notifications of Change 



OR 90 
OR 90 
OR 90 

OR 96 
OR 103 
OR 109 



OR 115 
OR 115 
OR 115 

OR 115 
OR 115 

OR 117 



APPENDIX VII- 



APPENDIXVIII 



APPENDIX IX - 



ACKNOWLEDGMENT ENTRIES 

7.1 Acknowledgment Entries 

7.2 Refused Acknowledgment Entries 

7.3 Table of Codes for Refused Acknowledgment Entries 

7.4 Record Formats for Acknowledgment and 
Refused Acknowledgment Entries 

RULE COMPLIANCE AUDIT REQUIREMENTS 

8.1 General Audit Requirements 

8.2 Audit Requirements for Participating DFIs 

8.3 Audit Requirements for ODFIs 

COMPENSATION RULES 

9.1 Scope 



OR 128 
OR 128 
OR 128 

OR 128 



OR 135 
OR 135 
OR 137 

OR 138 



OR 





9.2 


Nature of the Rules 




9.3 


Manner of Payment 




9.4 


Beneficiaries 




9.5 


Definitions 




9.6 


Back Valuation 




9.7 


Forward Valuation 




9.8 


Return or Reversal of Erroneous Entry 




9.9 


Change of Beneficiary 


APPENDIX X- 


ARBITRATION PROCEDURES 



APPENDIX XI 



2005 OPERA TING RULES 
OR139 
OR 139 
OR 139 
OR139 
OR 139 
OR 139 
OR 140 
OR 141 



10.1 Scope 

10.2 Filing a Complaint 

10.3 Classification of Disputes 

10.4 Selection of Arbitrators 

10.5 Presentation of the Case and the Decision 

10.6 Payment and Appeal 

THE NATIONAL SYSTEM OF FINES 

11.1 Scope 

1 1 .2 Reporting of Rules Violations 

113 National Association and Respondent Financial 
Institution Action on Report of Possible ACH 
Rules Violation 

1 14 ACH Rules Enforcement Panel 
11.5 Fines 



NACHA OPERATING RULES INDEX 



OR 141 
OR 141 
OR 142 
OR 142 
OR 143 
OR 143 

OR 144 
OR 144 

OR 144 
OR 145 
OR 145 

OR 147 



OR viii 



2005 OPERATING RULES PREFACE 



PREFACE 

OVERVIEW 

The rules of the National Automated Clearing House became effective January 1, 1977 for all member 
Automated Clearing House Associations. 

The framing and adoption of these rules represent the culmination of significant effort and achievement by 
NACH A representatives dedicated to the common goal of developing a national network of Automated 
Clearing House activities and services. These rules were developed in close coordination with 
representatives of the U.S. Treasury, Federal Reserve, and major industry groups. These rules govern the 
interregional exchange and settlement of Automated Clearing House transactions and should be used in 
conjunction with other official National Automated Clearing House Association operating guidelines and 
legal agreements in effect from time to time. 

ORGANIZATION AND STRUCTURE 

As changes or revisions to the rules are adopted, they will be reflected as amendments to this publication. 
Amendments will automatically be made available to each member ACH Association. Member ACH 
Associations are responsible for dissemination of amendments to their member financial institutions. 
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NACHA BOARD OF DIRECTORS 

POLICY STATEMENT ON DATA SECURITY 

The following Data Security Policy Statement was adopted by the Board of Directors on November 13,1986. 

The proposal sets a direction for the usage of industry-adopted and state-of-the-art security techniques in the 
ACH system. Additional implementation details are being addressed and will be announced upon 
completion. 



***** 




National Automated Clearing House Association 
Policy Statement on Data Security 

The National Automated Clearing House Association (NACHA) strongly supports the efforts of ACH 
participants to implement data security techniques through the policy stated herein: 

•;.'.■' NACHA recommends that ACH processors and all ACH participants employ data security 
techniques in accordance with ANSI standards for authentication and key management. When 
increased confidentiality is required, ANSI encryption standards are recommended for use. 

* NACHA will work with ACH Operators to implement data security techniques for various media 
and for exchanges between Operators. 

• On an ongoing basis, NACHA will stay abreast of new data security techniques and their 
applicability to the ACH system to ensure a high level of quality and reliability to all users of the 

■:'■■'■■■.': ACH. :■■■'.■■.'■.::.'■■■.■/■.■ 



***** 
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NACHA BOARD OF DIRECTORS 

POLICY STATEMENT ON ELECTRONIC TRANSMISSION 

BETWEEN ORIGINATORS AND ODFIs 



The following Electronic Transmission Policy Statement was adopted by the Board of Directors on 
November 21, 1997. 



* -k k k k 



National Automated Clearing House Association 
Policy Statement on Electronic Transmission 

The National Automated Clearing House Association (NACHA) strongly urges Originators and Originating 
Depository Financial Institutions (ODFIs) to operate in an all-electronic environment for ACH transactions. 
An all-electronic environment is defined as follows: 

One in which Originators and ODFIs interface with each other via a secured telecommunications link for all 
ACH related activity. This includes the origination and/or receipt of all current ACH transactions, related 
reports, returns, notifications of change, and any future related applications/ Also/ when applicable, RDFIs 
are encouraged to operate in a similar all-electronic environment when transmitting remittance data to 
corporate Receivers. 
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NACHA BOARD O^^^ 

POLICY STATEMENT ON 

FRAUD PREVENTION AND RISK MANAGEMENT INITIATIVES 



The Following Policy Statement on Fraud Prevention and Risk Management Initiatives was adopted by the 
Board of Directors on August 22, 2002. 
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National Automated Clearing House Association 
Policy Statement on Fraud Prevention and Risk Management Initiatives 



Fraud and various forms of financial abuse have found their way into every facet of the U.S. payment 
systems. The NACHA Board believes that the Automated Clearing House Network must maintain the 
highest standards of fraud prevention to retain the integrity of the payment mechanism and the trust and 
confidence of its users. Therefore, the NACHA Board resolves and strongly urges that all participants 
implement adequate control systems to detect and prevent fraud and abusive financial transactions. 
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ARTICLE ONE 



ARTICLE ONE - GENERAL 



SECTION 1.1 Application of Rules 

These rules apply to all entries and entry data transmitted 
through one or more ACH Operators, except where 
superseded by the operating rules of an Association by 
which an ODFI and RDFI have agreed to be bound. 
Unless a federal government entity or agency has 
expressly agreed to be bound by these rules, the rules do 
not apply to entries initiated by that entity or agency. 

SECTION 1.2 Compliance With Rules 

Each Participating DFI agrees to comply with these rules 
and warrants that it is legally able to comply with all 
applicable requirements of these rules. 

SUBSECTION 1.2.1 Audits 

Each Participating DFI shall conduct or have conducted 
audits of its compliance with these rules in accordance 
with Appendix Eight (Rule Compliance Audit 
Requirements). 

SUBSECTION 1.2.2 Compensation 

The settlement of claims for compensation between 
Participating DFIs may be governed by the procedures 
contained in Appendix Nine (Compensation Rules). 

SUBSECTION 1.2.3 Arbitration 

The settlement of disputes arising under these rules 
between Participating DFIs may be governed by the 
procedures contained in Appendix Ten (Arbitration 
Procedures). 

SUBSECTION 1 .2.4 Rules Enforcement 

Each Participating DFI is subject to, and agrees to comply 
with, the rules enforcement procedures contained in 
Appendix Eleven (Rules Enforcement). 

SECTION 1.3 Excused Delay 

Delay by a Participating DFI or ACH Operator beyond 
the time limits prescribed or permitted by these rules is 
excused if the delay was caused by the interruption of 
communication or computer facilities or the suspension of 
payments by another Participating DFI or ACH Operator, 
and the delay is beyond the reasonable control of the 
Participating DFI or ACH Operator. This may include, 
but is not limited to, delays caused by war or act of God, 
provided that the Participating DFI or ACH Operator 
exercises such diligence as the circumstances require. 
Delay caused by the general failure of a Participating 
DFFs computer facilities or other equipment does not 



constitute an excused delay and should be addressed 
within the Participating DFFs contingency planning 
policies. 

SECTION 1.4 Days on Which Institution or Facility 
is Closed 

Any entry or entry data required by these rules to be made 
available or transmitted by a Participating DFI or ACH 
Operator on or by a day that is not a banking day for both 
the sending party (sending DFI or sending ACH Operator) 
and receiving party (receiving DFI or receiving ACH 
Operator) may be made available or transmitted on the 
next day that is a banking day for both the sending and 
receiving parties. This rule only applies where an entry 
will be received on the same day it is transmitted. 

$ SECTION 1.5 Transmission of ACH Information Via 
Unsecured Electronic Networks 

Any banking information, including, but not limited to, an 
Entry, Entry Data, a routing number, an account number, 
and a PIN or other identification symbol, that is 
transmitted or exchanged between a Receiver and an 
Originator, an Originator and an ODFI, an ODFI and an 
ACH Operator, an ACH Operator and an RDFI, or an 
Originator, ODFI, RDFI, or ACH Operator and a Third- 
Party Service Provider, via an Unsecured Electronic 
Network, must, prior to the key-entry and through 
transmission of any banking information, ( 1 ) be encrypted 
using a commercially reasonable security technology that, 
at a minimum, is equivalent to 128-bit RC4 encryption 
technology, or (2) be transmitted via a secure session 
utilizing a commercially reasonable security technology 
that provides a level of security that, at a minimum, is 
equivalent to 128-bit RC4 encryption technology. 

Transmissions or exchanges of banking information over 
an Unsecured Electronic Network by means of voice or 
keypad inputs from a wireline or wireless telephone are 
not subject to this Section 1 .5 unless the telephone is used 
to access the Internet. 

SECTION 1.6 Records 

SUBSECTION 1.6.1 Records of Entries 

Each Participating DFI must retain records of all entries, 
including return and adjustment entries, transmitted from 
or to an ACH Operator. These records must be retained 
for six years from the date the entry was transmitted. The 
Participating DFI must, if requested by its customer, or 
any other Participating DFI or ACH Operator which 
originated, transmitted, or received the entry, provide the 
requester with a printout or reproduction of the 
information relating to the entry. A Participating DFI may 
impose a reasonable charge for the provision of such 
information. 
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SUBSECTION 1 .6.2 Record Retention 

Any agreement, authorization, written statement under 
penalty of perjury, or other record required by these rules 
may be retained as an electronic record that (1) accurately 
reflects the information in the record, and (2) is capable of 
being accurately reproduced for later reference, whether 
by transmission, printing, or otherwise. 

SUBSECTION 1.6.3 Electronic Records Permitted 

Any agreement, authorization, written statement under 
penalty of perjury, or other record required by these rules 
to be in writing may instead be in electronic form. Any 
record that is required to be signed or similarly 
authenticated may be signed with an electronic signature 
in conformity with the terms of the Electronic Signatures 
in Global and National Commerce Act (15 U.S.C. §7001, 
et seq.) and in a manner that evidences the identity of the 
person who signed and that person's assent to the terms of 
the record. Any record that is signed or similarly 
authenticated according to the terms of an applicable state 
version of the Uniform Electronic Transaction Act is 
deemed to be signed in conformity with the terms of the 
Electronic Signatures in Global and National Commerce 
Act. 

SECTION 1.7 Choice of Law 

These rules and the rights and obligations of a party with 
regard to a credit entry subject to Article 4A shall be 
construed in accordance with and governed by the laws of 
the State of New York, unless otherwise provided in an 
agreement of such party. 



ARTICLE TWO 
OF ENTRIES 



ORIGINATION 



SECTION 2.1 Prerequisites to Origination 

The following must occur before an Originator may 
initiate the first credit or debit entry to a Receiver or to a 
Receiver's account with an RDFI: 



SUBSECTION 2.1.1 
Agreement 



Originator Authorization and 



$ The Originator or a Third-Party Sender has authorized the 
ODFI to fransmit^and to credit or debit the amount of, 
one or more entries to the Receiver's account. For all 
entries except CIE, either (1) the Originator and ODFI 
have entered into an agreement under which the 
Originator agrees to be bound by these rules as in effect 
from time to time and acknowledges that entries may not 
be initiated that violate the laws of the United States, or 
(2) any Third-Party Sender has entered into an appropriate 
agreement under which the Third-Party Sender is bound 



by these rules as in effect from time to time and 
acknowledges that entries may not be initiated that violate 
the laws of the United States, and the Originator has 
entered into an appropriate agreement under which the 
Originator has assumed the responsibilities of an 
Originator under these rules and has acknowledged that 
entries may not be initiated that violate the laws of the 
United States. Each Third-Party Sender is subject to the 
requirements of Article Five (Obligations of Third-Party 
Senders). This subsection does not apply to XCK entries 
initiated pursuant to section 2.7 (Destroyed Check 
Entries). 



SUBSECTION 2.1.2 
Agreement 



Receiver Authorization and 



The Receiver has authorized the Originator to initiate the 
entry to the Receiver's account. In the case of CBR, CCD, 
and CTX entries, the Receiver has an agreement with the 
Originator under which the Receiver has agreed to be 
bound by these rules as in effect from time to time. In the 
case of debit entries to a Consumer Account, the 
authorization must be in writing and signed or similarly 
authenticated by the consumer. The similarly 
authenticated standard permits signed, written 
authorizations to be provided electronically. The writing 
and signature requirements are satisfied by compliance 
with the Electronic Signatures in Global and National 
Commerce Act (15 U.S.C. £7001 et seq.), which defines 
electronic records (as contracts or other records created, 
generated, sent, communicated, received, or stored by 
electronic means) and electronic signatures. Electronic 
signatures include, but are not limited to, digital 
signatures and security codes. The authorization process 
must evidence both the consumer's identity and his assent 
to the authorization. To meet the requirement that an 
authorization be in writing, an electronic authorization 
must be able to be displayed on a computer screen or 
other visual display that enables the consumer to read the 
communication. The authorization also must be readily 
identifiable as an authorization, must clearly and 
conspicuously state its terms, and, for all entries except 
POP entries and Single-Entry WEB entries, the 
authorization must provide that the Receiver may revoke 
the authorization only by notifying the Originator in the 
manner specified in the authorization. The authorization 
for ARC Entries consists of a notice meeting the 
requirements of subsection 2.1.4 (Notification for 
Accounts Receivable Entries) and the receipt of the 
Receiver's source document. The authorization for RCK 
entries consists of a notice meeting the requirements of 
subsection 2.1.5 (Notification for Re-presented Check 
Entries) and the receipt of the item to which the RCK 
entry relates. In the case of credit entries, the 
authorization may be provided orally or by other non- 
written means. Entries subject to subsections 2.1.3 
(Exception to Authorization Requirement) and 2.1.6 
(Authorization for Telephone-Initiated Entries) are 
excepted from these Receiver authorization requirements. 
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* [The Receiver has authorized the Originator to initiate 
the entry to the Receiver's account In the case ofCBR, 
CCD, and CTX entries, the Receiver has an agreement 
with the Originator under which the Receiver has agreed 
to be bound by these rules as in effect from time to time. 

In the case of credit entries to a Consumer Account, the 
authorization may be provided orally or by other non- 
written means. In the case of debit entries to a Consumer 
Account, the authorization must be in writing and signed 
or similarly authenticated by the consumer. The similarly 
authenticated standard permits signed, written 
authorizations to be provided electronically, and the 
authorization process must evidence both the consumer 's 
identity and his assent to the authorization. 

With respect to the use of electronic authorizations, an 
electronic authorization must be able to be displayed on 
a computer screen or other visual display that enables the 
consumer to read the communication. The writing and 
signature requirements are satisfied by compliance with 
the Electronic Signatures in Global and National 
Commerce Act (15 U.S.C. §7001 etseq.), which defines 
electronic records (as contracts or other records created, 
generated, sent, communicated, received, or stored by 
electronic means) and electronic signatures. Electronic 
signatures include, but are not limited to, digital 
signatures and security codes. 

The authorization must be readily identifiable as an 
authorization, must clearly and conspicuously state its 
terms, and, for all entries except POP entries and Single- 
Entry WEB entries, the authorization must provide that 
the Receiver may revoke the authorization only by 
notifying the Originator in the manner specified in the 
authorization. The authorization for ARC Entries 
consists of a notice meeting the requirements of 
subsection 2.1.4 (Notification for Accounts Receivable 
Entries) and the receipt of the Receiver's source 
document The authorization for RCK entries consists of 
a notice meeting the requirements of subsection 2.1.5 
(Notification for Re-presented Check Entries) and the 
receipt of the item to which the RCK entry relates. 

Entries subject to subsections 2.1.3 (Exception to 
Authorization Requirement) and 2.1.6 (Authorization for 
Telephone-Initiated Entries) are excepted from these 
Receiver authorization requirements.] 



SUBSECTION 2.13 
Requirement 



Exception to Authorization 



If both the Originator and Receiver are natural persons, no 
authorization by the Receiver is required for credit entries, 
and no warranty with respect to that authorization is made 
by the ODFI. No authorization by the Receiver is 
required for entries initiated pursuant to section 2.7 
(Destroyed Check Entries). The provisions of section 3.5 
(Consumer Accounts - Copy of Debit Authorization), 
section 3.12 (Record of Authorization), and subsection 



4.1.1 (Right to Information Regarding Entries) are not 
applicable to the entries described in this subsection 2. 1.3. 

SUBSECTION 2.1.4 Notification for Accounts 
Receivable Entries 

> Prior to the receipt of each source document that is used 
as the basis for the origination of an ARC entry, the 
Originator must provide the Receiver with a notice that 
clearly and conspicuously states that the receipt of the 
source document will authorize an ACH debit entry to the 
Receiver's account in accordance with the terms of the 
source document. If the Originator has received notice in 
accordance with the reasonable procedures established by 
the Originator that the receipt of the check does not 

, authorize an ACH debit entry, then receipt of a check by 
the Originator does not authorize an ACH debit entry to 
the account on which the check is drawn. 

SUBSECTION 2.1.5 Notification for Re-presented Check 
Entries 

Prior to the origination of each RCK entry, the Originator 
must provide the Receiver with a notice that clearly and 
conspicuously states the terms of the re-presented check 
entry policy in advance of receiving the item to which the 
RCK entry relates. 

SUBSECTION 2.1.6 Authorization for Telephone- 
Initiated Entries 

In the case of TEL entries, the Receiver has orally 
authorized the Originator to initiate a debit entry to a 
Consumer Account of the Receiver. The authorization 
must be readily identifiable as an authorization and must 
clearly state its terms. The following minimum 
information must be included as part of the authorization: 

the date on or after which the ACH debit to the 

Receiver's account will occur; 

the amount of the transaction; 

the Receiver's name; 

a telephone number for Receiver inquiries that is 

answered during normal business hours; 

the date of the Receiver's oral authorization; and 

a statement by the Originator that the 

authorization obtained from the Receiver is for 

a Single-Entry ACH debit. 

The Originator must either (1) tape record the oral 
authorization, or (2) provide the Receiver with written 
notice confirming the oral authorization prior to the 
Settlement Date of the entry. 

SUBSECTION 2.1.7 Automated Enrollment Entries 
(ENR) 

Participating IJFIs, at the request of an account holder at 
the DFI, may originate an ENR in accordance with 
Appendix Two (ACH Record Format Specifications). 
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SUBSECTION 2.1.8 Notice by ODFI 

In the case of a credit entry subject to Article 4 A, the 
ODFI shall have provided the Originator with notice of 
the following: 

(1 ) the entry may be transmitted through the ACH; 

(2) the rights and obligations of the Originator 
concerning the entry shall be governed by and construed 
in accordance with the laws of the State of New York, 
unless the Originator and the ODFI have agreed that the 
laws of another jurisdiction shall govern their rights and 
obligations; 

(3) credit given by the RDFI to the Receiver for the entry 
as provided in subsection ' 4.4.1 (Availability of Credit 
Entries to Receivers) is provisional until the RDFI has 
received final settlement through a Federal Reserve Bank 
or otherwise has received payment as provided for in 
Section 4A-403(a) of Article 4A; and 

(4) if the RDFI does not receive such payment for the 
entry, the RDFI is entitled to a refund from the Receiver 
in the amount of the credit to the Receiver's account, and 
the Originator will not be considered to have paid the 
amount of the credit entry to the Receiver. 

This notice may be included as part of an agreement 
entered into by the Originator binding the Originator to 
these rules, or it may be provided to the Originator 
separately. 

SUBSECTION 2.1.9 Notice by RDFI 

In the case of a credit entry subject to Article 4A, the 
RDFI has provided the Receiver with notice of the 
following information: 

(1) the entry may be transmitted through the ACH; 

(2) the rights and obligations of the Receiver concerning 
the entry shall be governed by and construed in 
accordance with the laws of the State of New York, unless 
the Receiver and the RDFI have agreed that the laws of 
another jurisdiction shall govern their rights and 
obligations; 

(3) credit given by the RDFI to the Receiver for the entry 
as provided by subsection 4.4.1 (Availability of Credit 
Entries to Receivers) is provisional until the RDFI has 
received final settlement through a Federal Reserve Bank 
or otherwise has received payment as provided for in 
Section 4A-403(a) of Article 4 A; 

(4) if the RDFI does not receive such payment for the 
entry, the RDFI is entitled to a refund from the Receiver 
in the amount of the credit to the Receiver's account, and 
the Originator will not be considered to have paid the 
amount of the credit entry to the Receiver; and 



(5) these rules do not require the RDFI to provide the 
Receiver with notice that the RDFI has received the entry 
unless the RDFI has agreed to do so. 

This notice may be included as part of an agreement 
entered into by the Receiver binding the Receiver to these 
rules, or it may be provided to the Receiver separately. 

SUBSECTION 2.1.10 ODFI Exposure Limits 

In the case of an entry sent or transmitted to an ODFI 
directly by an Originator that is not a natural person or by 
a Third-Party Sender, the ODFI has (1) established an 
exposure limit for that Originator or Third-Party Sender, 
(2) implemented procedures to review that exposure limit 
periodically, (3) implemented procedures to monitor 
entries initiated by that Originator or Third-Party Sender 
relative to its exposure limit across multiple settlement 
dates, and (4) implemented procedures to monitor the 
payments system risk associated with CBR and PBR 
entries sent or transmitted by that Originator or Third- 
Party Sender. 

SECTION 2.2 Warranties and Liabilities of 
Originating Depository Financial Institutions 

SUBSECTION 2.2.1 Warranties 

Each ODFI sending an entry warrants the following to 
each RDFI, ACH Operator, and Association: 

SUBSECTION 2.2.1.1 Authorization by Originator and 

Receiver 

Except in the case of XCK entries initiated pursuant to 
section 2.7 (Destroyed Check Entries), each entry 
transmitted by the ODFI to an ACH Operator is in 
accordance with proper authorization provided by the 
Originator and the Receiver. 

SUBSECTION 2.2.1.2 Timeliness of Entries 

Each credit entry is timely, and each debit entry is for an 
amount which on the Settlement Date will be due and 
owing to the Originator from the Receiver, is for a sum 
specified by the Receiver to be paid to the Originator, or 
is to correct a previously transmitted erroneous credit 
entry. 



SUBSECTION 

Requirements 



2.2.1.3 Compliance With Other 



All other applicable requirements of section 2.1 
(Prerequisites to Origination) concerning the authorization 
and entry have been satisfied, the entry has not been 
reinitiated in violation of section 2.12 (Reinitiation of 
Returned Entries by Originators), and the entry otherwise 
complies with these rules. 
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SUBSECTION 2.2.1.4 Revocation of Authorization 

♦ At the time the entry is transmitted to an Originating ACH 
Operator, the Originator's authorization has not been 
revoked, the agreements required by subsection 2.1.1 
(Originator Authorization and Agreement) concerning the 
entry have not been terminated, and neither the ODFI, any 
Third-Party Sender, nor the Originator has actual 
knowledge of the revocation of the Receiver's 
authorization or of the termination of the arrangement 
between the RDFI and the Receiver concerning the entry. 

SUBSECTION 2.2.1.5 Termination of Authorization bv 
Operation of Law 

At the time the entry is processed by an RDFI, the 
authorization for that entry has not been terminated, in 
whole or in part, by operation of law. This subsection 
shall not apply if the RDFI has actual knowledge of the 
circumstances giving rise to such termination at the time 
it processes the entry and the ODFI does not have such 
actual knowledge. 

SUBSECTION 2.2. 1 .6 Transmission of ACH Information 
Via Unsecured Electronic Networks 

For each entry for which any banking information, 
including, but not limited to, an Entry, Entry Data, a 
routing number, an account number, and a PIN or other 
identification symbol, is transmitted or exchanged 
between a Receiver and an Originator, or an Originator 
and an ODFI, via an Unsecured Electronic Network, the 
Originator has, prior to the key entry and through 
transmission of any banking information, (1) encrypted 
the banking information using a commercially reasonable 
security technology that, at a minimum, is equivalent to 
128-bit RC4 encryption technology, or (2) transmitted or 
received the banking information via a secure session 
using a commercially reasonable security technology that 
provides a level of security that, at a minimum, is 
a equivalent to 128-bit RC4 encryption technology. [For 
each entry for which any banking information, including, 
but not limited to, an Entry, Entry Data, a routing 
number, an account number, and a PIN or other 
identification symbol, is transmitted or exchanged 
between a Receiver and an Originator, an Originator and 
an ODFI, an ODFI and an ACH Operator, or an 
Originator or ODFI and a Third-Party Service Provider, 
via an Unsecured Electronic Network, the Originator has, 
prior to the key entry and through transmission of any 
banking information, (I) encrypted the banking 
information using a commercially reasonable security 
technology that, at a minimum, is equivalent to 128-bit 
RC4 encryption technology, or (2) transmitted or received 
the banking information via a secure session using a 
commercially reasonable security technology that 
provides a level of security that, at a minimum, is 
equivalent to 1 28-bit RC4 encryption technology.] 

Transmissions or exchanges of banking information over 
an Unsecured Electronic Network by means of voice or 



keypad inputs from a wireline or wireless telephone are 
not subject to this Subsection 2.2. 1 .6 unless the telephone 
is used to access the Internet. 

SUBSECTION 2.2.1.7 Verification of Identity of 
Originator 

The ODFI has utilized a commercially reasonable method 
to establish the identity of each Originator that uses an 
Unsecured Electronic Network to enter into a contractual 
relationship with an ODFI for the origination of ACH 
transactions. 

SUBSECTION 2.2.1.8 PIN Requirements 

If a personal identification number (PIN) is required in 
connection with the authorization for an MTE, POS, or 
SHR entry, the Originator has complied with the 
American National Standards Institute's (ANSI) 
Accredited Standards Committee (ASC) X9.8 concerning 
PIN Management and Security. This warranty does not 
apply to SHR or MTE entries if the ODFI and the RDFI 
are parties to an agreement (other than these rules) for the 
provision of services relating to these entries, or if a card 
issued by the ODFI or Originator of the entry is used in 
connection with the authorization for these entries. 




SUBSECTION 
Information 



2.2.1.9 Transmittal of Required 



Each entry transmitted by the ODFI to an ACH Operator 
contains the correct Receiver account number and all 
other information necessary to enable the RDFI to comply 
with the requirements of section4.5 (Periodic Statements) 
except for information within the purview of the RDFI's 
relationship with the Receiver. Information transmitted 
with an entry is payment related and conforms to the 
requirements of Appendix Two (ACH Record Format 
Specifications). 

SUBSECTION 2.2.1.10 Reclamation Entries 

(a) In the case of a reclamation entry initiated pursuant to 
section 2.6 (Reclamation Entries) or a written demand for 
payment initiated pursuant to section 4.8 (Liability of 
RDFI for Benefit Payments), all information is accurate 
and applies to the Receiver and account identified in the 
reclamation entry or written demand; (b) Each such 
reclamation entry or written demand for payment falls 
within the time requirements of section 4.8.4 (Timing), 
has been properly authorized by the intended Receiver of 
the reclamation entry or written demand, and the 
authorization for the entry or written demand has not been 
revoked or otherwise terminated at the time it is received 
by the RDFI; (c) Any payments subject to section 4.8 are 
made with no restriction on the number of parties having 
an interest in the account. 
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SI IBSECTION 2.2.1.11 Sending Points 

An entry containing the routing number of an ODFI which 
is transmitted to an ACH Operator by a Sending Point 
used by that ODFI to transmit entries to an ACH Operator 
on its behalf is transmitted pursuant to an agreement 
entered into between the ODFI and that Sending Point to 
transmit the entry. 

SUBSECTION 2.2.1.12 Audits 

The ODFI and any third-party service provider that has 
acted on behalf of the ODFI with regard to the entry are 
in compliance with the audit requirements set forth in ^ 
Appendix Eight (Rule Compliance Audit Requirements), 
which provide for an annual audit of compliance with 
these rules. 

SUBSECTION 2.2.1.13 Point-of-Purchase Entries 

For a POP entry, the source document provided to the 
Originator for use in obtaining the Receiver's routing 
number, account number, and check serial number for the 
initiation of such an entry is (1) returned voided to the 
Receiver after use by the Originator, and (2) has not been 
provided by the Receiver for use in any prior POP entry. 

SUBSECTION 2.2.2 Limitation 

Notwithstanding anything in these rules to the contrary, 
the warranties contained within subsection 2.2.1 
(Warranties) and the requirements of subsection 2.1.2 
(Receiver Authorization and Agreement) do not apply to 
the goods or services to which the entry relates. 

SUBSECTION 2.2.3 Liability for Breach of Warranty 

Each ODFI breaching any of the preceding warranties 
shall indemnify every RDFI, ACH Operator, and 
Association from and against any and all claim, demand, 
loss, liability, or expense, including attorneys' fees and 
costs, that result directly or indirectly from the breach of 
warranty or the debiting or crediting of the entry to the 
Receiver's account. This indemnity includes, without 
limitation, any claim, demand, loss, liability, or expense 
based on the ground that the debiting of an entry to an 
account resulted, either directly or indirectly, in the return 
of one or more items or entries of the Receiver due to 
insufficient funds. This indemnity also includes, in the 
case of a Consumer Account, without limitation, any 
claim, demand, loss, liability, or expense based on the 
ground that the failure of the ODFI to comply with any 
provision of these rules resulted, either directly or 
indirectly, in the violation by an RDFI of the Federal 
Electronic Fund Transfer Act or Federal Reserve Board 
Regulation E. 

SUBSECTION 2.2.4 Sending Points 

An ODFI shall be deemed to have made the warranties of 
subsection 2.2.1 (Warranties) for each entry described in 



subsection 2.2.1.1 1 (Sending Points) whether or not the 
Sending Point was authorized by the ODFI to transmit the 
entry. 

SECTION 2.3 Prenotifications 

SUBSECTION 2.3.1 General Rule 

Prior to the initiation of the first entry to a Receiver or a 
Receiver's account with an RDFI, an Originator may, at its 
option, deliver or send notification (referred to as 
"prenotification"), complying with the requirements of 
Appendix Two (ACH Record Format Specifications), 
through an ODFI to its ACH Operator for transmittal to 
the appropriate RDFI. The prenotification shall provide 
notice to the RDFI that the Originator intends to initiate 
one or more entries to that Receiver's account in 
accordance with the Receiver's authorization. If the 
Originator intends to initiate an entry on behalf of another 
person, any prenotification transmitted shall be 
transmitted with respect to such person. In any case in 
which a prenotification has been initiated by an 
Originator, the provisions of subsection 2.3.2 (Six 
Banking Days' Delay; Return Entries and Notification of 
Change) will apply. 

SUBSECTION 2.3 2 Six Banking Davs' Delay; Return 
Entries and Notification of Change 

Except as otherwise provided in this section 2.3, an 
Originator that has initiated a prenotification may initiate 
entries to a Receiver's account no sooner than six banking 
days following the Settlement Date of the prenotification 
entry. If, within the six banking day period, the RDFI has 
transmitted to its ACH Operator and the ODFI has 
received a return entry complying with the requirements 
of Appendix Five (Return Entries) indicating that the 
RDFI will not accept entries, such entries shall not be 
initiated. If, within the six banking day period, the RDFI 
has transmitted to its ACH Operator and the ODFI has 
received a Notification of Change complying with the 
requirements of Appendix Six (Notification of Change) 
indicating that the RDFI requires the requested changes to 
be made prior to the initiation of such entries, such entries 
shall not be initiated unless the requested changes have 
been made. 

SECTION 2.4 Reversing Files 

SUBSECTION 2.4.1 General Rule 

If an Originator, ODFI, or ACH Operator has mistakenly 
initiated a duplicate file or a file in which each entry or 
each entry in one or more batches contains erroneous data, 
and no right to recall those entries otherwise exists under 
these rules, the Originator, ODFI, or ACH Operator may 
initiate a file of entries (referred to as a "reversing file") 
in accordance with Appendix Two (ACH Record Format 
Specifications) and this section 2.4 to reverse each entry 
of the duplicate or erroneous file or batch(es). 
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SUBSECTION 2.4.2. 
Reversing Files 



Limitations on Initiation of 



Each reversing file must be initiated in such time as to be 
transmitted or made available to the RDFI(s) within five 
banking days after the Settlement Date of the duplicate or 
erroneous file or batch(es). In the case of a reversing file 
initiated by an Originator or ODFI, the file must be 
transmitted to the Originating ACH Operator within 24 
hours of the discovery of the duplication or error. In the 
case of a reversing file initiated by an ACH Operator, the 
file must be transmitted to the appropriate Receiving ACH 
Operator or RDFI within 24 hours of the discovery of the 
duplication or error. 

.SUBSECTION 2.4.3 Notification by ACH Operator 

At or prior to the time of initiation, any Receiving ACH 
Operator initiating a reversing file shall notify each 
Originating ACH Operator directly concerned, and any 
Originating ACH Operator initiating a reversing file shall 
notify each ODFI directly concerned of the duplication or 
error. 

SUBSECTION 2.4.4 Correcting Files 

A reversing file to correct an erroneous file or batch must 
be accompanied by a file (referred to as a "correcting 
file") which contains correct information. The correcting 
file must comply with the requirements of Appendix Two 
(ACH Record Format Specifications). 

SUBSECTION 2.4.5 Indemnification 

Each ODFI or ACH Operator that initiates a reversing or 
correcting file shall indemnify every Participating DFI, 
ACH Operator, and Association from and against any and 
all claim, demand, loss, liability, or expense, including 
attorneys' fees and costs, that result directly or indirectly 
from the debiting or crediting of any entry in the file to the 
Receiver's account. Each ODFI also shall indemnify 
every RDFI, ACH Operator, and Association from and 
against any and all claim, demand, loss, liability, or 
expense, including attorneys' fees and costs, resulting 
directly or indirectly from the crediting or debiting of any 
entry contained in a reversing or correcting file initiated 
by an Originator through the ODFI. 

SUBSECTION 2.4.6 Inapplicable Provisions 

For a reversing file complying with the requirements of 
this section, the provisions of sections 2.1 (Prerequisites 
to Origination), 2.2 (Warranties & Liabilities of ODFIs), 
and 3.4 (Consumer Accounts - Notice by Originator to 
Receiver of Variable Debits) do not apply. 



SECTION 2.5 Reversing Entries 

SUBSECTION 2.5.1 General Rule 

An Originator may initiate an entry (referred to as a 
"reversing entry") to correct an erroneous credit or debit 
entry previously initiated to a Receiver's account. The 
reversing entry must be transmitted to the Receiving ACH 
Operator in such time as to be transmitted or made 
available to the RDFI by midnight of the fifth banking day 
following the Settlement Date of the erroneous entry. For 
this section 2.5 only, an erroneous entry is defined as an 
entry that ( 1 ) is a duplicate of an entry previously initiated 
by the Originator or ODFI; (2) orders payment to or from 
a Receiver not intended to be credited or debited by the 
Originator; or (3) orders payment in a dollar amount 
different than was intended by the Originator. The 
Originator must notify the Receiver of the reversing entry 
and the reason for the reversing entry no later than the 
Settlement Date of the reversing entry. 

SUBSECTION 2.5.2 Indemnification 

Each ODFI that initiates a reversing entry shall indemnify 
every Participating DFI, ACH Operator, and Association 
from and against any and all claim, demand, loss, liability, 
or expense, including attorneys' fees and costs, that result 
directly or indirectly from the debiting or crediting of the 
reversing entry to the Receiver's account. Each ODFI also 
shall indemnify every RDFI, ACH Operator, and 
Association from and against any and all claim, demand, 
loss, liability, or expense, including attorneys' fees and 
costs, that result directly or indirectly from the crediting 
or debiting of a reversing entry initiated by an Originator 
through the ODFI. 

SUBSECTION 2.5.3 Inapplicable Provisions 

For a reversing entry complying with the requirements of 
this section 2.5, the provisions of sections 2.1.2 (Receiver 
Authorization and Agreement), 2.2.1.1 (Authorization by 
Originator and Receiver), 2.2.1.4 (Revocation of 
Authorization), 2.2. 1 .5 (Termination of Authorization by 
Operation of Law), and 3.4 (Consumer Accounts ~ Notice 
by Originator to Receiver of Variable Debits) do not 
apply. 

SECTION 2.6 Reclamation Entries 

SUBSECTION 2.6.1 General Rule 

An Originator or ODFI may initiate a reclamation entry in 
accordance with the requirements of this section 2.6, 
section 4.8 (Liability of RDFI for Benefit Payments), and 
Appendix Two (ACH Record Format Specifications). 

SUBSECTION 2.6.2 Definition 

A reclamation entry must contain a dollar value equal to 
or less than the pension, annuity, or other benefit payment 
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to which the reclamation entry relates, as provided for in 
section 4.8 (Liability of RDFI for Benefit Payments). 

SUBSECTION 2.6.3 Inapplicable Provisions 

For a reclamation entry complying with the requirements 
of this section 2.6, the provisions of sections 2.2.1.2 
(Timeliness of Entries), 2.2.1.4 (Revocation of 
Authorization), 2.2.1.5 (Termination of Authorization by 
Operation of Law), and 3 .4 (Consumer Accounts - Notice 
by Originator to Receiver of Variable Debits) do not 
apply. 

SECTION 2.7 Destroyed Check Entries 

SUBSECTION 2.7.1 General Rule 

If an eligible item as described in subsection 2.7.2 
(Eligible Item) is contained within a cash letter that has 
been lost, destroyed, or is otherwise unavailable to, and 
cannot be obtained by, an ODFI, the ODFI may initiate an 
XCK entry for that item in accordance with this section 
2.7 and Appendix Two (ACH Record Format 
Specifications). Notwithstanding subsection 14.1.24 
(definition of "entry"), an XCK entry is not deemed to be 
an item under Article 4 of the Uniform Commercial Code, 
and neither transmittal to nor receipt by an RDFI of an 
XCK entry shall constitute presentment of the destroyed 
item. 

SUBSECTION 2.7.2 Eligible Item 

To be eligible for this section, an item must be (1) an item 
within the meaning of Article 4 of the Uniform 
Commercial Code, (2) a negotiable demand draft drawn 
on or payable through or at an office of a Participating 
DFI, other than a Federal Reserve Bank or Federal Home 
Loan Bank, (3) in an amount less than $2,500, and (4) 
lost, destroyed, or otherwise unavailable while in transit 
for presentment to a paying bank. Examples of items 
which are not eligible for this section include noncash 
items, drafts drawn on the Treasury of the United States, 
drafts drawn on a state or local government that are not 
payable through or at a bank, United States Postal Service 
money orders, items payable in a medium other than U.S. 
money, return items, and items that are rejected during 
processing by the ODFI. 

SUBSECTION 2.7.3 Warranties 

In addition to the other warranties contained within these 
rules, each ODFI initiating an XCK entry pursuant to this 
section 2.7 warrants to each RDFI, ACH Operator, and 
Association that: 



SUBSECTION 2.7.3.1 
Check 



Good Title to the Destroyed 



obtain payment or acceptance on behalf of one who has 
good title or is entitled to enforce the item. 

SUBSECTION 2.7.3.2 Signatures are Genuine 

All signatures on the item to which the XCK entry relates 
are authentic and authorized. 

SUBSECTION 2.7.3.3 Destroyed Check Entry Not 
Altered 

The item to which the XCK entry relates has not been 
altered. 

SUBSECTION 2.7.3.4 No Defenses 

The item to which the XCK entry relates is not subject to 
a defense or claim in recoupment of any party that can be 
asserted against the ODFI. 

SUBSECTION 2.7.3.5 No Knowledge of Insolvency 

The ODFI has no knowledge of any insolvency 
proceeding commenced with respect to the maker or 
acceptor or, in the case of an unaccepted draft, the drawer 
of the item to which the XCK entry relates. 



SUBSECTION 2.7.3.6 
Accurately Reflects Item 



Destroyed Check Entry 



The ODFI has good title to or is entitled to enforce the 
item to which the XCK entry relates or is authorized to 



The item to which the XCK entry relates is drawn on, 
payable through, or payable at the RDFI, and the amount 
of such item, the item number, and account number 
contained on such item have been accurately reflected in 
the XCK entry. 

SUBSECTION 2.7.3.7 Item Will Not Be Presented 

The item to which the XCK entry relates or a copy of such 
item has not been and will not be presented to the RDFI. 

SUBSECTION 2.7.4 Liability for Breach of Warranty 

Each ODFI breaching any of the warranties contained 
within subsection 2.7.3 (Warranties) shall indemnify 
every RDFI, ACH Operator, and Association from and 
against any and all resulting claim, demand, loss, liability, 
or expense, including attorneys' fees and costs. 

SUBSECTION 2.7.5 Copy of Item 

An RDFI that receives an XCK entry may send to the 
ODFI that initiated the entry a written request for a copy 
of the item to which the entry relates. Such request must 
be received by the ODFI within six years of the date on 
which it initiated the XCK entry. Upon receipt of the 
written request, the ODFI must send to the RDFI a copy 
of the item within 30 days. 
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SUBSECTION 2.7.6 Return of a Destroyed Check Entry SUBSECTION 2.8.3 ODFI Warranties 



Notwithstanding anything in these rules to the contrary, an 
RDFI may return an XCK entry by transmitting a return 
entry to its' ACH Operator by midnight of the sixtieth day 
following the Settlement Date of the XCK entry. 

SECTION 2.8 Re-presented Check Entries 

SUBSECTION 2.8.1 General Rule 

If an eligible item as described in subsection 2.8.2 
(Eligible Item) is returned by a Participating DFI to a DFI, 
an ODFI may initiate an RCK entry in accordance with 
this section 2.8 and Appendix Two (ACH Record Format 
Specifications). As provided for in subsection 14.1.45 
("RCK entry"), an RCK entry shall be deemed to be a 
presentment notice for purposes of Revised Article 4 of 
the Uniform Commercial Code (1990 Official Text); 
receipt of the RCK entry shall constitute presentment of 
the item pursuant to Article 4-1 10 and return of the RCK 
entry shall constitute notice of dishonor or non-payment 
pursuant to Article 4-301. The provisions of these rules 
that are applicable to RCK entries are in accordance with 
the Commentary provisions set forth in 12 C.F.R. Part 
229.37 of Federal Reserve Regulation CC ("Regulation 

cc"). 

SUBSECTION 2.8.2 Eligible Item 

An RCK entry must relate to an item that (1) is an item 
within the meaning of Revised Article 4 of the Uniform 
Commercial Code ( 1 990 Official Text); (2) is a negotiable 
demand draft drawn on or payable through or at a 
Participating DFI, other than a Federal Reserve Bank or 
Federal Home Loan Bank; (3) contains a pre-printed 
serial number; (4) is in an amount less than $2,500; (5) 
indicates on the face of the document that the item was 
returned due to "Not Sufficient Funds," "NSF," 
'Uncollected Funds," or comparable language; (6) is 
dated 180 days or less from the date the entry is being 
transmitted to the RDFI (i.e., the item to which the RCK 
entry relates is not stale dated); (7) is drawn on a 
Consumer Account; and (8) has been previously presented 
(a) no more than two times in its physical form, if the 
entry is an initial RCK entry; or (b) no more than one time 
in its physical form and no more than one time as an RCK 
entry, if the entry is a reinitiated RCK entry pursuant to 
subsection 2.12 (Reinitiation of Returned Entries by 
Originators). 

Ineligible items include, but are not limited to, noncash 
items (as defined in Section 229.2(u) of Regulation CC); 
drafts drawn on the Treasury of the United States, a 
Federal Reserve Bank, or a Federal Home Loan Bank; 
drafts drawn on a state or local government that are not 
payable through or at a Participating DFI; United States 
Postal Service money orders; items payable in a medium 
other than United States currency; items which are third- 
party items; and demand drafts and third-party drafts that 
do not contain the signature of the Receiver. 



In addition to the other warranties contained within these 
rules, each ODFI initiating an RCK entry pursuant to this 
section 2.8 warrants to each RDFI, ACH Operator, and 
Association that: 

SUBSECTION 2.8.3.1 Good Title to the Returned Item 

The ODFI has good title or is entitled to enforce the item 
to which the RCK entry relates or is authorized to obtain 
payment or acceptance on behalf of one who has good 
title or is entitled to enforce the item. 

SUBSECTION 2.8.3.2 Signatures Are Genuine 

All signatures on the item to which the RCK entry relates 
are authentic and authorized. 

SUBSECTION 2.8.3.3 Item Not Altered 

The item to which the RCK entry relates has not been 
altered. 

SUBSECTION 2.8.3.4 No Defenses 




The item to which the RCK entry relates is not subject to 
a defense or claim in recoupment of any party that can be 
asserted against the ODFI. 

SUBSECTION 2.8.3.5 No Knowledge of Insolvency 



The ODFI has no knowledge of any insolvency 
proceeding commenced with respect to the maker or 
acceptor, or, in the case of an unaccepted draft, the drawer 
of the item to which the RCK entry relates. 



SUBSECTION 2.8.3.6 Entry Accurately Reflects Item 

The item to which the RCK entry relates is drawn on, 
payable through, or payable at the RDFI, and the amount 
of the item, the item number, and the account number 
contained on the item have been accurately reflected in 
theRCK entry. 

SUBSECTION 2.8.3.7 Item Will Not Be Presented 

Subsequent to the origination of an RCK entry, the item 
to which the RCK entry relates or a copy of such item will 
not be presented to the RDFI unless the related RCK entry 
has been returned by the RDFI. 

SUBSECTION 2.8.3.8 Encoding Is Correct 



The information encoded after issue in magnetic ink on 
the item is correct. 
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SUBSECTION 2,8,3.9 Restrictive Endorsement is Void 
or Ineffective 




The Originator has agreed that any restrictive 
endorsement made by the Originator or its agent on the 
item to which the RGK entry relates is void or ineffective 
upon initiation of the RCK entry. 

SUBSECTION 2.8.3.10 Request for Copy of Item 

An RDFI that receives an RCK entry may send to the 
ODFI that initiated the RCK entry a written request for a 
copy of the front and back of the item to which the RCK 
entry relates. If the item has been finally paid, the copy 
must indicate this on its. face. The written request must be 
received by the ODFI within seven (7) years of the 
Settlement Date of the RCK entry. Upon receipt of the 
written request, the ODFI warrants to the RDFI that it will 
send a copy of the front and back of the item within ten 
(10) banking days; 

SUBSECTION 2.8.3.11 Liability for Breach of Warranty 

Each ODFI breaching any of the warranties contained 
within subsection 2.8.3 (ODFI Warranties) shall 
indemnify every RDFI, ACH Operator, and Association 
from and against any and all resulting claim, demand, 
loss, liability, or expense, including attorneys' fees and 
costs, resulting directly or indirectly from the breach of 
these warranties. 

SUBSECTION 2.8.4 Return of a Re-presented Check 
Entry 

Each RCK return entry must be transmitted to the RDFFs 
ACH Operator by midnight of the second banking day 
following the banking day of receipt of the presentment 
notice. 

SECTION 2.9 Accounts Receivable Entries 

SUBSECTION 2.9.1 Source Documents 



Reserve Bank, or a Federal Home Loan Bank, (7) checks 
drawn on a state or local government, or (8) checks 
payable in a medium other than United States currency. 

SUBSECTION 2.9.2 Capture of MICR Information 



For an ARC entry, a check or sharedraft provided to the 
Originator by the Receiver via the U.S. mail or at a 
dropbox location must be used by the Originator as the 
source document for the Receiver's routing number, 
account number, check serial number, and dollar amount. 
To be used as the source document for an ARC entry, a 
check or sharedraft must (1) contain a pre-printed serial 
number, (2) be drawn on a Consumer Account, and (3) be 
completed and signed by the Receiver. 

The following may not be used as the source document for 
ARC entries: (1) checks drawn on corporate or business 
accounts, (2) third-party checks, (3) demand drafts and 
third-party drafts that do not contain the signature of the 
Receiver, (4) credit card checks, (5) obligations of a 
financial institution (e.g., travelers checks, cashier's 
checks, official checks, money orders, etc.), (6) checks 
drawn on the Treasury of the United States, a Federal 



During initial processing of an ARC entry, the Originator 
may not key-enter the routing number, account number, or 
check serial number from the Receiver's source 
document. An Originator may, however, key-enter such 
information to correct errors relating to MICR misreads, 
misencoding, or processing rejects. 

SUBSECTION 2.9.3 ODFI Warranties 

In addition to the other warranties contained within these 
rules, each ODFI initiating an ARC entry pursuant to this 
section 2.9 warrants to each RDFI, ACH Operator, and 
Association that: 

SUBSECTION 2.9.3.1 Entry Information is Accurate 

The amount of the entry, the routing number, the account 
number, and the check serial number are in accordance 
with the source document 

SUBSECTION 2.9.3.2 Copy of Source Document 

The Originator must retain a reproducible, legible, image, 
microfilm, or copy of the front of the Receiver's source 
document for each ARC entry for two years from the 
Settlement Date of the ARC entry. An RDFI that receives 
an ARC entry may send to the ODFI that originated the 
entry a written request for a copy of the source document 
to which the ARC entry relates. The RDFI 's written 
request must be received by the ODFI within two years of 
the Settlement Date of the ARC entry. Upon receipt of the 
written request, the ODFI warrants to the RDFI that it will 
send a copy of the front of the Receiver's source 
document within ten ( 1 0) banking days . The copy must 
indicate that it is a copy on its face. 

SUBSECTION 2.9.3.3 Source Document Will Not Be 
Presented for Payment 

The source document to which the ARC entry relates will 
not be presented or returned such that any person will be 
required to make payment based on the source document. 
In addition to each RDFI, ACH Operator, and 
Association, this warranty runs to any other party that may 
be liable on the source document. 

SUBSECTION 2.9.3.4 Destruction of Source Document 

The source document to which the ARC entry relates must 
be destroyed within fourteen days of the Settlement Date 
of the entry. 
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SUBSECTION 2.9.3.5 Liability for Breach of Warranty 

Each ODFI breaching any of the warranties contained 
within subsection 2.9.3 (ODFI Warranties) shall 
indemnify every RDFI, ACH Operator, Association, and 
any other party covered by the warranty from and against 
any and all resulting claim, demand, loss, liability, or 
expense, including attorneys' fees and costs, resulting 
directly or indirectly from the breach of these warranties. 
In addition, in the case of a Consumer Account, the ODFI 
indemnifies every RDFI, ACH Operator, Association, and 
any other party covered by the warranty from and against 
any and all resulting claim, demand, loss, liability, or 
expense based on the ground that the failure of the ODFI 
to comply with any provision of these rules resulted, 
either directly or indirectly, in the violation by an RDFI of 
the Federal Electronic Fund Transfer Act or Federal 
Reserve Board Regulation E. 

SECTION 2.10 Internet-Initiated Entries 

SUBSECTION 2.10.1 General Rule 

A WEB entry may be transmitted by an Originator 
pursuant to an authorization that is obtained from the 
Receiver via the Internet to effect a transfer of funds from 
a Consumer Account of the Receiver. 



SUBSECTION 2.10.2 ODFI Warranties 

In addition to the other warranties contained within these 
rules, each ODFI initiating a WEB entry pursuant to this 
section 2.10 warrants to each RDFI, ACH Operator, and 
Association that: 

SUBSECTION 2.10.2.1 Fraud Detection Systems 

Each Originator for which the ODFI transmits WEB 
entries has employed a commercially reasonable 
fraudulent transaction detection system to screen each 
entry. 



$ [SUBSECTION 
Identity 



2.10.2.2 Verification of Receiver's 



For each WEB entry, the Originator has employed 
commercially reasonable methods of authentication to 
verify the identity of the Receiver] 

SUBSECTION 2.10.2.3 ODFI Exposure Limits 

In the case of a WEB entry sent or transmitted to an ODFI 
directly by an Originator that is not a natural person or by 
a Third-Party Sender, the ODFI has (1) established 
procedures to monitor, on an on-going basis, the credit- 
worthiness of the Originator or Third-Party Sender, (2) 
established an exposure limit for the Originator or Third- 
Party Sender, (3) implemented procedures to review that 
exposure limit periodically, and (4) implemented 
procedures to monitor entries sent or transmitted by the 



^ Originator or Third-Party Sender relative to its exposure 
limit across multiple settlement dates. 

SUBSECTION 2. 1 0.2.4 Verification of Routing Numbers 



Each Originator that originates WEB entries has used 
commercially reasonable procedures to verify that routing 
numbers are valid. 

SUBSECTION 2. 10.2.5 WEB Annual Audit 

Each Originator that originates WEB entries shall conduct 
or have conducted annual audits to ensure that the 
financial information it obtains from Receivers is 
protected by security practices and procedures that 
include, at a minimum, adequate levels of (1) physical 
security to protect against theft, tampering, or damage, (2) 
personnel and access controls to protect against 
unauthorized access and use, and (3) network security to 
ensure secure capture, storage, and distribution. 

SUBSECTION 2. 10.2.6 Liability for Breach of Warranty 

Each ODFI breaching any of the warranties contained 
within subsection 2.10.2 (ODFI Warranties) shall 
indemnify every RDFI, ACH Operator, Association, and 
any other party covered by the warranty from and against 
any and all resulting claim, demand, loss, liability, or 
expense, including attorneys ' fees and costs, resulting 
directly or indirectly from the breach of these warranties. 
In addition, in the case of a Consumer Account, the ODFI 
shall indemnify every RDFI, ACH Operator, Association, 
and any other party covered by the warranty from and 
against any and all resulting claim, demand, loss, liability, 
or expense based on the ground that the failure of the 
ODFI to comply with any provision of these rules 
resulted, either directly or indirectly, in the violation by an 
RDFI of the Federal Electronic Fund Transfer Act or 
Federal Reserve Board Regulation E. 

SECTION 2.11 Telephone-Initiated Entries 

SUBSECTION 2.11.1 General Rule 




A TEL entry may be transmitted by an Originator 
pursuant to an oral authorization that is obtained from the 
Receiver via the telephone to effect the transfer of funds 
from a Consumer Account of the Receiver. 

SUBSECTION 2.1 1.2 ODFI Warranties 

In addition to the other warranties contained within these 
rules, each ODFI initiating a TEL entry pursuant to this 
section 2. 1 1 warrants to each RDFI, ACH Operator, and 
Association that: 



$ Approved November 9, 2004; Effective March 18, 2005 
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SUBSECTION 2. 1 1 .2.1 Verification of Receiver's 
Identity 

For each TEL entry, the Originator has employed 
commercially reasonable procedures to verify the identity 
of the Receiver. 

SI JESECTION 2. 11.2.2 Verification of Routing Numbers 

For each TEL entry, the Originator has utilized 
commercially reasonable procedures to verify that routing 
numbers are valid. 




SUBSECTION 
Re quirements 



2.11.3 TEL Entry Reporting 



Where the National Association believes that the return 
rate for TEL entries that are returned as unauthorized for 
one or more Originators using the ODFI directly, or 
through a Third-Party Service Provider, to initiate TEL 
entries may exceed 2.5%, the National Association may 
request, in writing, that an ODFI provide the National 
Association with the following information: 

•■'■.'■'. the actual return rate for unauthorized TEL 
entries for any Originator when computed by (1) 
dividing the number of TEL entries returned as 
unauthorized for the preceding 60 days by the 
total number of TEL entries contained in the file 
in which the original entries were transmitted, or 
(2) dividing the number of TEL entries returned 
as unauthorized by the total number of TEL 
entries originated for the preceding 60 days; and 

where the Originator's return rate for TEL 
entries that are returned as unauthorized exceeds 
2.5%, the ODFI must also provide: 

(1) the name, address, telephone number, 
contact person, principal owner(s), and 
taxpayer identification number of the 
Originator, and, if applicable, each 
Third-Party Service Provider acting on 
behalf of the Originator with respect to 
the origination of TEL entries; 

(2) a general description of the nature of 
the business of the Originator; and 

(3) an explanation of the Originator's 
reason(s) for the excessive return rate. 

Each ODFI must provide the requested information to the 
National Association within ten banking days of receipt of 
the National Association's written request to the ODFFs 
Chief Operating Officer. The failure of an ODFI to 
provide such information in a timely manner will be 
considered to be willful disregard of these rules and may 
result in the imposition of a fine in accordance with the 
requirements of Appendix Eleven, subsection 1 1.5.3 



(Amount of Fine and Recurrence of ACH Rules 
Violation). 

SECTION -2.12 Reinitiation of Returned Entries by 
Originators 

For all entries except RCK entries, an entry that has been 
returned may not be reinitiated unless (1) the entry has 
been returned for insufficient or uncollected funds; (2) the 
entry has been returned for stopped payment and 
reinitiation has been authorized by the Receiver; or (3) the 
ODFI has taken corrective action to remedy the reason for 
the return. An entry that has been returned for insufficient 
or uncollected funds may be reinitiated no more than two 
times following the return of the original entry. 

For RCK entries, an entry that has been returned may not 
be reinitiated unless (1) the RCK entry has been returned 
for insufficient or uncollected funds, and (2) the item to 
which the RCK entry relates has been presented no more 
than one time in its physical form and no more than one 
time as an RCK entry. 



SECTION 2.13 
Requirements 



Media and Format Specification 



Each entry transmitted by an ODFI to its ACH Operator 
must comply with the requirements of and be identified by 
the appropriate Standard Entry Class Code specified in 
Appendix Two (ACH Record Format Specifications). 

SECTION 2.14 Release of Information 

Each ODFI agrees that each ACH Operator may release 
to the National Association data regarding ACH return 
entries transmitted to or by the ODFI. 



ARTICLE THREE - OBLIGATIONS 
OF ORIGINATORS 



SECTION 3.1 Genera! 

In addition to the requirements of section 2.1 
(Prerequisites to Origination) concerning the initiation of 
entries, an Originator must comply with the requirements 
contained within this Article Three. 



SECTION 3.2 
Requirements 



MTE; PQS, and SHR Entry FIN 



If a personal identification number (PIN) is required in 
connection with the authorization for an MTE, POS, or 
SHRentry,the Originator must comply with the American 
National Standards Institute's (ANSI) Accredited 
Standards Committee (ASC) X9. 8 concerning PIN 
Management and Security. This provision does not apply 
to SHR or MTE entries if the ODFI and the RDFI are 
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parties to an agreement (other than these rules) for the 
provision of services relating to these entries, or if a card 
issued by the ODFI or Originator of the entry is used in 
connection with the authorization for these entries . 

♦ SECTION 3.3 Transmission of ACH Information Via 
Unsecured Electronic Networks 

For each entry for which any banking information, 
including, but not limited to, an Entry, Entry Data, a 
routing number, an account number, and a PIN or other 
identification symbol, is transmitted or exchanged 
between a Receiver and an Originator, or an Originator 
and an ODFI, via an Unsecured Electronic Network, the 
Originator must, prior to the key entry and through 
transmission of any banking information, ( 1 ) encrypt the 
banking information using a commercially reasonable 
security technology that, at a minimum, is equivalent to 
128-bit RC4 encryption technology, or (2) transmit or 
receive the banking information via a secure session 
utilizing a commercially reasonable security technology 
that provides a level of security that, at a minimum, is 
equivalent to 128-bit RC4 encryption technology. [For 
each entry for which any banking information, including, 
but not limited to, an Entry, Entry Data, a routing 
number, an account number, and a PIN or other 
identification symbol, is transmitted or exchanged 
between a Receiver and an Originator, an Originator and 
an ODFI, or an Originator and a Third-Party Service 
Provider, via an Unsecured Electronic Network, the 
Originator must, prior to the key entry and through 
transmission of any banking information, (I) encrypt the 
banking information using a commercially reasonable 
security technology that, at a minimum, is equivalent to 
128-bit RC4 encryption technology, or (2) transmit or 
receive the banking information via a secure session 
utilizing a commercially reasonable security technology 
that provides a level of security that, at a minimum, is 
equivalent to 128-bit RC4 encryption technology.] 

Transmissions or exchanges of banking information over 
an Unsecured Electronic Network by means of voice or 
keypad inputs from a wireline or wireless telephone are 
not subject to this Section 3.3 unless the telephone is used 
to access the Internet. 

SECTION 3.4 Consumer Accounts -— Notice bv 
Originator to Receiver of Variable Debits 

SUBSECTION 3.4.1 Notice of Change in Amount 

If the amount of a debit entry to be initiated to a 
Consumer Account differs from the amount of the 
immediately preceding debit entry relating to the same 
authorization or from a preauthorized amount, the 
Originator must send the Receiver written notification of 
the amount of the entry and the date on or after which the 
entry will be debited. The Originator must send the 
Receiver written notice at least ten calendar days prior to 
the date on which the entry is scheduled to be initiated. 



SUBSECTION 3.4.2 Receiver's Election 

If the Originator informs the Receiver of the Receiver's 
right to receive notification concerning a change in the 
amount of a debit entry, the Receiver may choose to 
receive notice only if the amount of the entry falls outside 
a specified range or if the entry differs from the most 
recent entry by more than an agreed upon amount. 



SUBSECTION 3.4.3 
Debiting Date 



Notice of Change in Scheduled 



If an Originator changes the date on or after which entries 
to be initiated by the Originator are scheduled to be 
debited to a Receiver's account, the Originator shall send 
to the Receiver written notification of the new date on or 
after which entries initiated by the Originator are 
scheduled to be debited to the Receiver's account Such 
notification shall be sent within not less than seven 
calendar days before the first entry to be affected by the 
change is scheduled to be debited to the Receiver's 
account. For purposes of this subsection 3 .4.3 , variation 
in debiting dates due to Saturdays, Sundays, or holidays 
are not considered to be changes in the scheduled dates. 




SECTION 3.5 Consumer Accounts 
Authorization 



Copy of Debit 



An Originator must provide each Receiver with an 
electronic or hard copy of the Receiver's authorization for 
all debit entries to be initiated to a Consumer Account. 

SECTION 3.6 Obligations of Originators of RCK 
Entries 

SUBSECTION 3.6.1 Restrictive Endorsements Made Bv 
the Originator or Its Agent 

A restrictive endorsement made by the Originator or its 
agent on the item to which the RCK entry relates is void 
or ineffective with respect to an RCK entry. 

SUBSECTION 3.6.2 Notice Obligation 

The Originator must provide the Receiver with notice that 
clearly and conspicuously states the terms of the re- 
presented check entry policy in advance of receiving the 
item to which the RCK entry relates. 

SUBSECTION 3.6.3 Copy of Item 

The Originator must retain a copy of the front and back of 
the item to which the RCK entry relates for seven (7) 
years from the Settlement Date of the RCK entry. At the 
request of the ODFI, the Originator must provide the copy 
of the front and back of the item to the ODFI for its use or 
for the use of an RDFI requesting the information 
pursuant to subsection 2.8.3.10 (Request For Copy of 
Item). If the item has been finally paid, the copy of the 
item must indicate this on its face. 



> Approved [December 2, 2003; Effective September 10, 2004 
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SECTION 3.7 Obligations of Originators of ARC 

Entries 

SI IBSECTION 3 .7 . 1 Notice Obligation 

The Originator must, in advance of receiving from the 
Receiver each source document used as the basis for the 
origination of an ARC entry, provide the Receiver with 
notice that clearly and conspicuously states that receipt of 
the Receiver's source document will authorize an ACH 
debit entry to the Receiver's account in accordance with 
the terms of the source document. If the Originator has 
received notice in accordance with the reasonable 
procedures established by the Originator that the receipt 
ofthe check does not authorize an ACH debit entry, then 
receipt of a check by the Originator does not authorize an 
ACH debit entry to the account on which the check is 
drawn. 

SUBSECTION 3.7.2 Source Documents 

For an ARC entry, a check or share draft provided to the 
Originator by the Receiver via the U.S. mail or at a 
dropbox location must be used by the Originator as the 
source document for the Receiver's routing number, 
account number, check serial number, and dollar amount. 
To be used as the source document for an ARC entry, a 
check or sharedraft must (1) contain a pre-printed serial 
number, (2) be drawn on a Consumer Account, and (3) be 
completed and signed by the Receiver. 

The following may not be used as the source document for 
ARC entries: (1) checks drawn on corporate or business 
accounts, (2) third-party checks, (3) demand drafts and 
third-party drafts that do not contain the signature of the 
Receiver, (4) credit card checks, (5) obligations of a 
financial institution (e.g, travelers checks, cashier's 
checks, official checks, money orders, etc.), (6) checks 
drawn on the Treasury of the United States, a Federal 
Reserve Bank, or a Federal Home Loan Bank, (7) checks 
drawn on a state or local government, or (8) checks 
payable in a medium other than United States currency. 

SUBSECTION 3.7.3 Copy of Source Document 



The Originator must retain a reproducible, legible, image, 
microfilm, or copy of the front of the Receiver's source 
document for each ARC entry for two years from the 
Settlement Date of the ARC entry. At the request of the 
ODFI, the Originator must provide a copy of the front of 
the source document to the ODFI for its use or for the use 
of an RDFI requesting such information pursuant to 
subsection 2.9.3.2 (Copy of Source Document). 

SUBSECTION 3.7.4 Source Document Will Not Be 
Presented for Payment 

The source document to which the ARC entry relates may 
not be used by the Originator as a check to obtain 
payment. 



SUBSECTION 3.7.5 Destruction of Source Document 

The source document to which the ARC entry relates must 
be destroyed within fourteen days of the Settlement Date 
of the entry. 

SUBSECTION 3.7.6 Capture of MICR Information 

During initial processing of an ARC entry, the Originator 
may not key-enter the routing number, account number, or 
check serial number from the Receiver's source 
document. An Originator may, however, key-enter such 
information to correct errors relating to MICR misreads, 
misencoding, or processing rejects. 



SECTION 3.8 

Entries 



Obligations of Originators of POP 



SUBSECTION 3.8.1 Source Documents 

For a POP entry, a check or sharedraft provided by the 
Receiver at the point-of-purchase must be used by the 
Originator as a source document for the Receiver's 
routing number, account number, and check serial 
number. The source document must then be voided by the 
Originator. Only a check or sharedraft that contains a pre- 
printed serial number and that is drawn on a Consumer 
Account may be used as a source document for this type 
of transaction. 

For POP entries, the following may not be used as source 
documents: (1) checks drawn on corporate or business 
deposit accounts, (2) third-party checks, (3) credit card 
checks, (4) obligations of a financial institution (e.g., 
traveler's checks, cashier's checks, official checks, money 
orders, etc.), (5) checks drawn on the Treasury of the 
United States, a Federal Reserve Bank, or a Federal Home 
Loan Bank, (6) checks drawn on a state or local 
government, or (7) checks payable in a medium other than 
United States currency. For POP entries, a previously 
voided check or sharedraft that has been used by the 
Receiver for a prior POP entry may not be used as a 
source document for this type of transaction; 

SUBSECTION 3.8.2 Capture of MICR Information 

The Originator may not key-enter the routing number, 
account number, or check serial number from the 
Receiver's source document. 



SUBSECTION 3.8.3 Receipts 

An Originator must provide to each Receiver a receipt 
containing the following information with respect to each 
POP entry to the Receiver's account: 

(a) Originator name (merchant) 

(b) company (merchant)/third-party service 
provider telephone number; 

(c) date of transaction; 

(d) transaction amount; 
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(e) source document check serial number; 

(f) merchant number (or other unique number that 
identifies the location of the transaction); 

(g) Terminal City; and 
(h) Terminal State. 

The National Association strongly recommends, but these 
rules do not require, that the Originator also provide the 
following information on the receipt provided to the 
Receiver: 

(a) merchant address; 

(b) merchant identification number; 

(c) Receiver's financial institution routing number; 

(d) Receiver's truncated account number; 

(e) Receiver's truncated identification number; and 

(f) transaction reference number. 

Note: The Receiver's complete account number and 
complete identification number are not permitted to be 
placed on the receipt. 

SECTION 3.9 Obligations of Originators of Internet- 
Initiated Entries 



SUBSECTION 3.9.1 Fraud Detection Systems 

Each Originator originating WEB entries must employ a 
commercially reasonable fraudulent transaction detection 
system to screen each entry. 

SUBSECTION 3.9.2 Verification of Routing Numbers 

Each Originator that originates WEB entries must use 
commercially reasonable procedures to verify that routing 
numbers are valid. 

$ \ SUBSECTION 3. 9. 3 Verification of Receiver 's Identity 

Each Originator that originates WEB en tries must employ 
commercially reasonable methods of authentication to 
verify; the identity of the Receiver. ] 

SUBSECTION 3.9.4 Security of Internet Session 

Each Originator that originates WEB entries must 
establish a secure Internet session with each Receiver 
utilizing a commercially reasonable security technology 
providing a level of security that, at a minimum, is 
equivalent to 128-bit encryption technology prior to the 
Receiver's key entry and through transmission to the 
Originator of any banking information, including, but not 
limited to, the Receiver's routing number, account 
number, and personal identification number (PIN) or other 
identification symbol. 

SUBSECTION 3.9.5 WEB Annual Audit 



protected by security practices and procedures that 
include, at a minimum, adequate levels of (1) physical 
security to protect against theft, tampering, or damage, (2) 
personnel and access controls to protect against 
unauthorized access and use, and (3) network security to 
ensure secure capture, storage, and distribution. 

SECTION 3.10 Obligations of Originators of 
Telephone-Initiated Entries 

SUBSECTION 3.10,1 Verification of Receiver Identity 

Each Originator that initiates TEL entries must employ 
commercially reasonable procedures to verify the identity 
of the Receiver; 



SUBSECTION 3.10.2 Verification of Routing Numbers 

Each Originator that initiates TEL entries must use 
commercially reasonable procedures to verify that routing 
numbers are valid. 

SECTION 3.11 Payment to ODFI 

Each Originator that utilizes a Third-Party Sender to 
authorize an ODFI to transmit credit or debit entries 
agrees to make payment to the ODFI for any such credit 
entries originated and for any debit entries returned by the 
RDFI to the extent that the ODFI does not receive 
payment from the Third-Party Sender. 

SECTION 3.12 Record of Authorization 

An Originator must retain the original or a microfilm or 
microfilm-equivalent copy of each authorization of a 
Receiver for two years from the termination or revocation 
of the authorization. In the case of TEL entries, the 
Originator must retain the original or a microfilm or 
microfilm-equivalent copy of the written notice or the 
original or a duplicate tape recording of the oral 
authorization for two years from the date of the 
authorization. At the request of its ODFI, the Originator 
must provide the original or copy of the authorization to 
the ODFI for its use or for the use of an RDFI requesting 
the information pursuant to subsection 4.1.1 (Right to 
Information Regarding Entries). This section 3.12 does 
not apply to SHR or MTE entries if the ODFI and RDFI 
are parties to an agreement (other than these rules) for the 
provision of services relating to SHR or MTE entries. 




Each Originator that originates WEB entries shall conduct 
or have conducted annual audits to ensure that the 
financial information it obtains from Receivers is 
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ARTICLE FOUR- 
ENTRIES 



RECEIPT OF 



SECTION 4.1 
RDFI 



General Rights and Obligations of 



SUBSECTION 4.1.1 
Entries 



Right to Information Regarding 




An RDFI may request, in writing, that an ODFI provide a 
copy of the Receiver's authorization for any entries other 
than CBR entries, CCD entries, CTX credit entries, and 
XCK debit entries. Upon receipt of the RDFI's written 
request, the ODFI must obtain the original or a copy of 
the Receiver's authorization from the Originator in 
accordance with Section 3.12 (Record of Authorization) 
and provide it to the RDFI within ten banking days. An 
ODFI must provide such authorization without charge. 
The RDFI must not require the Originator to provide any 
other information concerning the Receiver or any entry to 
be initiated by the Originator to the Receiver's account. 
This subsection 4.1.1 does not apply to SHR or MTE 
entries if the ODFI and RDFI are parties to an agreement 
(other than these rules) for the provision of services 
relating to SHR or MTE entries. For ARC entries, the 
authorization shall consist of a copy of the notice 
provided under subsection 2.1.4 (Notification for 
Accounts Receivable Entries) and a copy of the 
Receiver's source document. The copy of the source 
document must indicate that it is a copy on its face. For 
RCK entries, the authorization shall consist of a copy of 
the notice provided under subsection 2.1.5 (Notification 
for Re-presented Check Entries) and a copy of the item to 
which the RCK entry relates. 



SUBSECTION 4. 1 .4 Reliance on Account Numbers for 
Posting of Entries 

If the account number and the name of the Receiver 
contained in an entry do not relate to the same account, 
the RDFI may rely solely on the account number 
contained in the entry for purposes of posting the entry to 
the Receiver's account. 

SECTION 4.2 Warranties of Receiving Depository 
Financial Institutions 

Each RDFI warrants to each ODFI, ACH Operator, and 
Association that it has the power under applicable law to 
receive entries as provided in these rules and to comply 
with the requirements of these rules concerning RDFIs 
and Participating DFIs. Each RDFI also warrants that the 
RDFI and any third-party service provider that has acted 
on behalf of the RDFI with regard to the entry are in 
compliance with the audit requirements set forth in 
Appendix Eight (Rule Compliance Audit Requirements), 
which provides for an annual audit of compliance with 
these rules. In addition to the other warranties contained 
within these rules, each RDFI receiving an RCK entry will 
(a) display the descriptive information contained in the 
Entry on the relevant periodic statement sent to the 
Receiver by the RDFI; and (b) accord the Receiver the 
same rights with respect to the RCK entry as are provided 
for items under Revised Article 4 of the 1990 Official 
Text of the Uniform Commercial Code, except as 
otherwise provided for within the RDFI's agreement with 
the Receiver/Any RDFI breaching any warranty under 
this section 4.2 shall indemnify each ODFI, ACH 
Operator, and Association from and against any and all 
claim, demand, loss, liability, or expense, including 
attorneys' fees and costs, resulting directly or indirectly 
from the breach of warranty. 



SUBSECTION 4. 1 .2 Obligation to Verify Prenotification SECTION 4.3 Receipt and Availability of Entries 



If a prenotification has been initiated by an Originator, the 
RDFI receiving the prenotification must verify that the 
account number contained in the prenotification is for a 
valid account. If the RDFI finds that a prenotification 
does not contain a valid account number, or is otherwise 
erroneous or unprocessable, it must reject the 
prenotification and transmit a return entry complying with 
the requirements of Article Six (Return, Adjustment, 
Correction, and Acknowledgment of Entries and Entry 
Information) and Appendix Five (Return Entries). 

SUBSECTION 4.1.3 Obligation to Accept Entries 

Subject to its right to return or reject entries under these 
rules, an RDFI must accept credit, debit, and zero dollar 
entries that comply with these rules and are received with 
respect to any account maintained with that RDFI. The 
RDFI also must accept prenotifications that comply with 
the provisions of these rules relating to prenotifications. 



An entry or entry data is deemed to be received by an 
RDFI on the banking day on which the entry or entry data 
is made available to it or to a Receiving Point used by the 
RDFI. An entry or entry data is made available to an 
RDFI or its Receiving Point when the entry or entry data 
is processed by the RDFI's ACH Operator and is ready for 
distribution. 



SECTION 4.4 Availability of Entries and Entry 
Information, Crediting and Debiting of Entries 



SUBSECTION 4.4.1 
Receivers 



Availability of Credit Entries to 



Subject to its right to return or reject entries in accordance 
with these rules, each RDFI must make the amount of 
each credit entry received from its ACH Operator 
available to the Receiver for withdrawal or cash 
withdrawal no later than the Settlement Date of the entry, 
with the following exception. Each PPD credit entry that 
is made available to an RDFI by its ACH Operator by 
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5:00 p.m. (RDFI's local time) on the banking day prior to 
the Settlement Date must be made available to the 
Receiver for withdrawal or cash withdrawal at the opening 
of business on the Settlement Date. For purposes of the 
preceding sentence, opening of business is defined as the 
later of 9:00 a.m. (RDFI's local time) or the time the 
RDFI's teller facilities (including ATMs) are available for 
customer account withdrawals. 

SUBSECTION 4.4.2 Time of Debiting of Entries 

An RDFI must not debit the amount of any entry to a 
Receiver's account prior to the Settlement Date of the 
entry, even if the effective entry date of the entry is 
different from the Settlement Date of the entry. 

SUBSECTION 4.4.3 Provision of Payment-Related 
Information to Receiver 

Upon the request of the Receiver, an RDFI must provide 
to its Receiver all Payment-Related Information contained 
within the Addenda Records transmitted with CCD, CIE, 
and CTX entries. The RDFI must provide this 
information to its Receiver by the opening of business on 
the second banking day following the Settlement Date of 
the entry. 

SUBSECTION 4.4.4 Crediting of Originators' Accounts 
by Receiver 

A Receiver must credit the Originator with the amount of 
an entry credited to the Receiver's account as of the 
Settlement Date. The Receiver shall have a reasonable 
period of time after the entry is credited to the Receiver's 
account to post the amount of the credit to the Originator's 
account or return the entry to the RDFI. For purposes of 
this section, a Receiver shall be considered to act within 
a reasonable period of time if the Receiver posts the credit 
or returns the entry no later than the time at which the 
Receiver would usually complete the process of posting 
credits resulting from payments received to its customers' 
accounts or returning these payments. A Receiver that 
returns an entry according to the requirements of this 
subsection 4.4.4 is not considered to have accepted the 
entry. This subsection 4.4.4 does not apply to MTE,POS, 
PPD, or SHR entries. 

SUBSECTION 4.4.5 Rights of Receiver Upon 
Unauthorized Debit to Its Account 

A Receiver or other person whose account is debited by 
an entry which is, in whole or in part, not authorized by 
such person shall have rights, including the right to have 
the account recredited as provided by law or agreement. 
Except as provided for in subsection 8.6.7 (Waiver of 
Right to Recredit), these rules shall not provide for or 
restrict any such rights. 



SUBSECTION 4.4.6 Reliance on Standard Entry Class 
Codes 

An RDFI may consider an entry containing a Standard 
Entry Class Code specified in Appendix Two (ACH 
Record Format Specifications) as complying with the 
requirements of these rules for that type of entry. 

SUBSECTION 4.4.7 Reimbursement of RDFI 

For a credit entry subject to Article 4A, credit given to the 
Receiver by the RDFI as provided in subsection 4.4. 1 
(Availability of Credit Entries to Receivers) is provisional 
until the RDFI has received final settlement through a 
Federal Reserve Bank or has otherwise received payment 
as provided in Section 4A-403(a) of Article 4A. If such 
settlement or payment is not received, the RDFI is entitled 
to a refund from the Receiver of the amount credited, and 
the Originator is considered not to have paid the Receiver 
the amount of the entry. This subsection applies only if 
the Receiver has agreed to be bound by the rules 
contained in this subsection 4.4.7. 

SECTION 4.5 Periodic Statements 

An RDFI must send or make available to each of its 
Receivers information concerning each credit and debit 
entry to a Consumer Account of the Receiver in 
accordance with Appendix Four (Minimum Description 
Standards). In the case of CIE entries, this requirement 
and the requirements of Appendix Four apply to the ODFI 
for each credit entry debited to a Consumer Account of 
the Originator. 

SECTION 4.6 Notice to Receiver 

An RDFI is not required to notify a Receiver of receipt of 
an entry to its account unless otherwise provided for in an 
agreement between the RDFI and Receiver or required by 
a federal or state statute or regulation which cannot be 
varied by these rules or by agreement of the parties. 

SECTION 4.7 Release of Information 

Each RDFI agrees that each ACH Operator may release to 
the National Association data regarding ACH return 
entries transmitted to or by the RDFL 

SECTION 4.8 Liability of RDFI for Benefit Payments 

SUBSECTION 4.8.1 Liability of RDFI 




If a Receiver has died and the Receiver's right to receive 
one or more pension, annuity, or other benefit payments 
by PPD entry has terminated before the receipt by the 
RDFI of one or more credit entries to the Receiver's 
account representing those payments, the RDFI may be 
liable to the Originator for the amount of those entries 
credited to the Receiver's account if neither the Receiver's 
estate nor any other holder of the account is entitled to the 
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payments. The liability an RDFI would incur under this 
subsection 4.8.1 is limited as provided in this section 4.8. 

SUBSECTION 4.8.2 Amount of RDFI Liability 

An RDFI's liability under this section 4.8 shall be the 
lesser of (1) the amount of any payments to which the 
Receiver was not entitled, or (2) the amount in the 
Receiver's account at the time the RDFI receives (i) a 
reclamation entry initiated by the ODFI pursuant to 
section 2.6 (Reclamation Entries) and not returned by the 
RDFI or (ii) a written demand for payment from the ODFI 
or Originator pursuant to subsections 4.8,3 (Demand for 
Payment) and 4.8.4 (Timing) and has a reasonable 
opportunity to act upon such demand. A claim or demand 
by an Originator (or ODFI on the Originator's behalf) will 
be subordinate to claims or potential claims of the United 
States Government under 31 C.F.R. Part 210. The 
Originator must reimburse the RDFI for any payments 
made to the Originator pursuant to this section 4.8 that are 
subject to a subsequent claim of the United States 
Government under 3 1 C.F.R. Part 21 0. 

SUBSECTION 4.8.3 Demand for Payment 

An RDFI will have no liability under this section 4.8 
unless and until it receives (1) a reclamation entry 
initiated by the ODFI pursuant to section 2.6 
(Reclamation Entries) and not returned by the RDFI , or 
(2) a written demand for payment from the ODFI or 
Originator. The reclamation entry or written demand for 
payment must identify the name of the Receiver, the 
account at the RDFI credited on the Receiver's behalf, and 
the exact amount and approximate date of initiation for 
each entry involved, 

SUBSECTION 4.8.4 Tuning 

A reclamation entry must be originated or a written 
demand for payment sent within five banking days after 
the Originator receives notice of the death of the Receiver. 
If a reclamation entry is returned by the RDFI, the 
Originator may make a written demand for payment 
within 15 banking days after it receives the returned 
reclamation entry. For this subsection, notice received by 
the Originator is considered to be effective from the time 
specified in Section 1-201(27) of the Uniform 
Commercial Code (1978 Official Text). 

SUBSECTION 4.8.5 Alteration by Agreement 

Notwithstanding any other provision of these rules, the 
liability provisions contained within this section 4.8 may 
be altered, amended, or superseded by a written 
agreement between the Originator and RDFI only if the 
agreement clearly and conspicuously states on its face that 
it is a master agreement, that both the Originator and 
RDFI consider it to be a master agreement, and that it is 
applicable to all payments subject to this section 4.8 sent 
by the Originator to the RDFI for the benefit of all 
Receivers having accounts at the RDFI. No provision of 



these rules prevents an RDFI from expressly agreeing in 
a master agreement that the liability provisions of this 
section 4.8 may be altered, amended, or superseded on a 
Receiver-by-Receiver basis. 

SECTION 4.9 RDFI Receipt of Death Notification 
Entry 

SUBSECTION 4.9.1 Notification of Death 

Receipt of a DNE entry constitutes notice of death. Only 
an agency of the Federal Government may originate such 
entries. 



♦ ARTICLE FIVE - OBLIGATIONS 
OF THIRD-PARTY SENDERS 

SECTION 5.1 Identification of Originators 

Each Third-Party Sender must, upon the ODFI's request, 
provide the ODFI with any information the ODFI 
reasonably deems necessary to identify each Originator 
for which it transmits entries. Such information must be 
provided to the ODFI by the Third-Party Sender within 
two banking days of receipt of the ODFI's request. 

SECTION 5.2 Warranty and Indemnification of 
Third-Party Sender 



Each Third-Party Sender authorizing the ODFI to 
transmit, and to credit or debit the amount of, one or more 
entries to the Receiver's account warrants to the ODFI 
that the Originator has agreed to assume the 
responsibilities of an Originator under these rules. In any 
case where such Originator fails to perform its obligations 
as an Originator under these rules, the Third-Party Sender 
authorizing such entry indemnifies the ODFI from and 
against any and all claim, demand, loss, liability, or 
expense, including attorneys' fees and costs, that result 
directly or indirectly from the failure of the Originator to 
perform its obligations as an Originator under these rules. 

SECTION 5.3 Assumption of ODFI Warranties 

Each Third-Party Sender warrants to the ODFI that the 
Third-Party Sender makes the warranties and assumes the 
liabilities of an ODFI under the following rules: 



2.2 



2.8 
2.9 
2.10 



Warranties and Liabilities of Originating 
Depository Financial Institutions (excluding the 
warranties in subsections 2.2.1.11* [Sending 
Points], 2.2.1.12 [Audits], and 2.2.4 [Sending 
Points]); 

Re-presented Check Entries; 
Accounts Receivable Entries; 
Internet-Initiated Entries; and 
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♦ 1 1.4 ODFI Warranties for Outbound Cross-Border 
Entries. 

SECTION 5.4 Payment to ODFI 

The Third-Party Sender agrees to make payment to the 
ODFI for any credit entries originated and for any debit 
entries returned by the RDFI. 

SECTION 5.5 Assumption of ODFI Responsibilities 

For the purposes of the following rules, a Third-Party 
Sender is considered to be a Participating DFI or an 
ODFI, as appropriate: 

1 .2 Compliance With Rules (excluding subsections 

1.2.1 [Audits], 1.2.2 [Compensation], 1.2.3 
[Arbitration], and 1.2.4 [Rules Enforcement]); 

2.14 Release of Information; and 

8.1 Recall by ODFI or Originator. 

SECTION 5.6 Assumption of Originator 
Responsibilities 

For the purposes of providing copies of documents to an 
ODFI under the following rules, a Third-Party Sender is 
considered to be the Originator: 

3.6.3 Copy of Item; 

3.7.3 Copy of Source Document; and 

3.12 Record of Authorization. 



ARTICLE SIX -RETURN, 
ADJUSTMENT, CORRECTION, 
AND ACKNOWLEDGMENT OF 
ENTRIES AND ENTRY 
INFORMATION 

SECTION 6.1 Return of Entries 

SUBSECTION 6.1.1 Right to Return Entries 

Except as otherwise provided for in subsection 6.1.3 
(Restrictions on Right to Return), an RDFI may return an 
entry for any reason. 

SUBSECTION 6.1.2 Requirements of Returns 

Each return entry must comply with the requirements of 
Appendix Five (Return Entries). Except as otherwise 
provided in this section 6.1, subsection 6.3.2 (ODFI and 
Originator Action on Notification of Change), subsection 
2.7.6 (Return of a Destroyed Check Entry), and 
subsection 2. 8.4 (Return of a Re-presented CheckEntry), 
each return entry must be received by the RDFI ' s ACH 
Operator by its deposit deadline for the return entry to be 



made available to the ODFI no later than the opening of 
business on the second banking day following the 
Settlement Date of the original entry. For purposes of the 
preceding sentence, the term second banking day shall 
refer to the second banking day of the RDFI's ACH 
Operator, and the term Settlement Date of the original 
entry shall refer to the Settlement Date of the original 
entry that is being returned. A return entry relating to a 
credit entry subject to Article 4A must be transmitted by 
the RDFI to its ACH Operator prior to the time the RDFI 
accepts the credit entry as provided for under Article 4 A, 
unless the Receiver of the entry does not have an account 
with the RDFI, the Receiver's account has been closed, or 
the RDFI is not permitted by law to receive credits for the 
Receiver's account. A return entry which is rej ected by an 
ACH Operator does not meet or extend the deadline 
contained in this section 6.1. 

SUBSECTION 6.1.3 Restrictions on Right to Return 

An RDFI may not return an entry because it is a credit, 
debit, or zero dollar entry or is a particular type of credit, 
debit, or zero dollar entry. An RDFI may not return a 
prenotification because it relates to credit or debit entries 
or to a particular type of credit or debit entry. An RDFI 
may, however, return any XCK debit entry or any entry 
received (including prenotification) that concerns any 
account that is not a "transaction account" (as defined in 
Regulation D of the Board of Governors of the Federal 
Reserve System) maintained with that RDFI. 

SUBSECTION 6.1.4 Credit Entries Returned by 
Receiver 

An RDFI may return any credit entry that is returned to it 
by a Receiver as provided for in subsection 4.4.4 
(Crediting of Originators' Accounts by Receiver). The 
RDFI must transmit the return entry to the ACH Operator 
by midnight of the banking day following the banking day 
of receipt by the RDFI from the Receiver. * 

SUBSECTION 6. 1 .5 Return of Unposted Credit Entries 

An RDFI must return all credit entries that are not 
credited or otherwise made available to its Receivers' 
accounts by midnight of the banking day following the 
Settlement Date. 

SUBSECTION 6.1.6 Acceptance of Return Entries by 
QDFI 

An ODFI must accept return entries complying with 
Appendix Five (Return Entries) and transmitted by the 
RDFI within the time limits established by these rules. 

SUBSECTION 6.1.7 Reinitiation of Return Entries by 

■QDn;; ; .V:.^ 

For all entries except RCK entries, an entry that has been 
returned may not be reinitiated unless (1) the entry has 
been returned for insufficient or uncollected funds; (2) the 
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entry has been returned for stopped payment and 
reinitiation has been authorized by the Receiver; or (3) the 
ODFI has taken corrective action to remedy the reason for 
the return. An entry that has been returned for insufficient 
or uncollected funds may be reinitiated no more than two 
times following the return of the original entry. 

For RCK entries, an entry that has been returned may not 
be reinitiated unless ( 1 ) the RCK entry has been returned 
for insufficient or uncollected funds, and (2) the item to 
which the RCK entry relates has been presented no more 
than one time in its physical form and no more than one 
time as an RCK entry. 

SUBSECTION 6.1.8 Reliance on DFI Account Number 

An RDFI may not return an entry to a transaction account 
based exclusively on data which was accurately obtained 
from the on-us field of the MICR line of a check or share 
draft for the account. This does not prevent the RDFI 
from initiating a notification of change and returning 
future entries if the notification of change is not properly 
acted upon. 



SECTION 6.2 Dishonor of Return Entries 

SUBSECTION 6.2. 1 Dishonor of Return by ODFI 

An ODFI may dishonor a return entry (1) if it can 
substantiate that the RDFI failed to return the entry within 
the time limits established by these rules, thus causing 
either the ODFI or Originator to suffer a loss, or (2) if the 
return entry contains incorrect information, does not 
include all information required by Appendix Five 
(Return Entries), or otherwise fails to comply with the 
requirements of Appendix Five. To dishonor a return 
entry, the ODFI must transmit a dishonored return entry 
complying with Appendix Five to its ACH Operator 
within five banking days after the Settlement Date of the 
return entry. 

SUBSECTION 6.2.2 Contesting of Dishonored Returns 
by RDFI 

An RDFI may dispute a dishonored return entry based on 
an untimely return entry, if the return entry was, in fact, 
returned within the time limits established by these rules, 
by initiating a contested dishonored return entry. A 
contested dishonored return entry must comply with the 
requirements of Appendix Five (Return Entries) and must 
be transmitted to the ACH Operator within two banking 
days after the Settlement Date of the dishonored return 
entry. The ODFI must accept a contested dishonored 
return entry transmitted by the RDFI and complying with 
this section 6.2. 

SUBSECTION 6.23 Contesting a Contested Dishonored 
Return 

An ODFI may not contest a contested dishonored return 
received from an RDFI by reinitiating the entry. Any 



further action concerning a contested dishonored return 
must be pursued outside of the ACH. 

SUBSECTION 6.2.4 Corrected Returns 

An RDFI receiving a dishonored return entry based on a 
return entry containing incorrect information, failing to 
contain all information required by Appendix Five 
(Return Entries), or otherwise failing to comply with the 
requirements of Appendix Five may transmit a corrected 
return entry to its ACH Operator within two banking days 
of the Settlement Date of the dishonored return entry. The 
corrected return entry must comply with the requirements 
of Appendix Five and must include the dishonored return 
information received from the ODFI. The ODFI must 
accept a corrected return entry transmitted by an RDFI in 
accordance with this subsection 6.2.4. 

SECTION 6.3 Notification of Change 

SUBSECTION 6.3.1 Notifications of Change; RDFI 
Warranties and Indemnity 

An RDFI may transmit a notification of change (NOC) to 
its ACH Operator provided that (1) the notification of 
change complies with the requirements of Appendix Six 
(Notification of Change), and (2) except for NOCs due to 
merger, acquisition, or other similar events, the NOC is 
transmitted within two banking days of the Settlement 
Date of the entry to which the NOC relates. Each RDFI 
that transmits an NOC or corrected NOC as provided for 
in subsection 6.4.2 (RDFI Action on Refused Notification 
of Change) warrants to each ODFI, ACH Operator, and 
Association that (1) the information contained within the 
NOC or corrected NOC is correct, and (2) if the change 
relates to the Receiver's account number, the Receiver has 
authorized the change, if authorization is required, and the 
RDFI has complied with any applicable legal 
requirements for such authorization. The RDFI's warranty 
supersedes and renders inoperative any similar warranty 
(but not any other warranty) of the ODFI contained within 
subsection 2.2.1 (Warranties). Any RDFI that breaches 
the warranties of this subsection 6.3.1 shall indemnify 
each ODFI, ACH Operator, and Association from and 
against any and all claim, demand, loss, liability, or 
expense, including attorneys' fees and costs, resulting 
directly or indirectly from the breach of warranty. 

SUBSECTION 6.3.2 ODFI and Originator Action on 
Notification of Change 

Unless otherwise provided for in this Article Six, an ODFI 
must accept NOCs and corrected NOCs that comply with 
the requirements of Appendix Six (Notification of 
Change) and that are transmitted by the RDFI within the 
time limits established by these rules. EachODFI must, at 
a minimum, provide to the Originator information relating 
to NOCs and corrected NOCs in accordance with the 
requirements of Appendix Six. The Originator must make 
the changes specified in the NOC or corrected NOC 
within six banking days of receipt of the NOC information 
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or prior to initiating another entry to the Receiver's 
account, whichever is later. 

SECTION 6.4 Refused Notification of Change 

SUBSECTION 6.4. 1 ODFI Right to Refuse Notification 
of Change Entries 

An ODFI may refuse an NOC or corrected NOC if ( 1 ) the 
NOC or corrected NOC contains incorrect information, 
(2) the NOC or corrected NOC does not contain all 
information required by Appendix Six (Notification of 
Change), or (3) the NOC otherwise fails to comply with 
Appendix Six. To refuse an NOC or corrected NOC, the 
ODFI must transmit an automated refused notification of 
change complying with Appendix Six to the Originating 
ACH Operator within fifteen days of receipt of the NOC 
or corrected NOC. 



SUBSECTION 6.4.2 
Notification of Change 



RDFI Action on Refused 



An RDFI may transmit a corrected NOC complying with 
Appendix Six (Notification of Change) to the Receiving 
ACH Operator within five banking days after the 
Settlement Date of the refused NOC, 

SECTION 6.5 Acknowledgment Entries 

SUBSECTION 6.5.1 General Rule 

An RDFI may, at its' option, transmit an acknowledgment 
entry, complying with the requirements of Appendix 
Seven (Acknowledgment Entries), to its ACH Operator 
for transmittal to the appropriate ODFI. The 
acknowledgment entry provides verification that a 
corporate credit entry has been received by the RDFI. 
Each acknowledgment entry initiated in response to a 
CCD or CTX credit entry must be received by the RDFI's 
ACH Operator by its deposit deadline for the 
acknowledgment entry to be made available to the ODFI 
no later than the opening of business on the second 
banking day following the Settlement Date of the CCD or 
CTX entry to which the acknowledgment relates. For 
purposes of the preceding sentence, the term second 
banking day shall refer to the second banking day of the 
RDFI's ACH Operator. 

SUBSECTION 6.5.2 Refused Acknowledgment Entries 

An ODFI may refuse an acknowledgment entry if ( 1 ) the 
acknowledgment entry contains incorrect information, (2) 
the acknowledgment entry does not contain all 
information required by Appendix Seven 
(Acknowledgment Entries), or (3) the acknowledgment 
entry otherwise fails to comply with Appendix Seven. To 
refuse an acknowledgment entry, the ODFI must transmit 
a refused acknowledgment entry, complying with the 
requirements of Appendix Seven, to the Originating ACH 
Operator within fifteen days of receipt of the 
acknowledgment entry. 



ARTICLE SEVEN - SETTLEMENT 
AND AGGOUNTABILITY 



SECTION 7.1 
Accounts 



Maintenance of Reserve Bank 



Each Participating DFI must maintain, or have the use 
through a correspondent of, an account with a Federal 
Reserve Bank. 

SECTION 7.2 Settlement 

Settlement among Participating DFIs for entries, 
adjustment entries, and return entries transmitted in 
accordance with these rules will be effected by the 
crediting and debiting of the Federal Reserve Bank 
accounts of Participating DFIs referred to in section 7.1 
(Maintenance of Reserve Bank Accounts). Settlement 
must be made in accordance with these rules, applicable 
operating circulars of the Federal Reserve Banks, and any 
other applicable agreements. 

SECTION 7.3 Effect of Settlement 

Settlement of entries does not preclude a Participating 
DFI from pursuing any available legal rights or remedies 
concerning any entry, adjustment entry, or return entry, 
including without limitation any right or remedy arising 
out of a return entry or adjustment entry, transmitted after 
the time limits established by these rules. 

SECTION 7.4 Accountability for Entries 

Each RDFI is accountable for the amount of all debit 
entries received that are not returned in accordance with 
these rules, except as provided for in subsection 6.3.2 
(ODFI and Originator Action on Notification of Change). 
The RDFI's accountability under this section is not 
affected by the failure of the ODFI to comply with the 
provisions of section 6.2 (Dishonor of Return Entries). 

SECTION 7,5 Effect of RDFI Closing on Time of 
Settlement 

If the scheduled Settlement Date of a debit entry is not a 
banking day for the RDFI but is a day on which the 
applicable office of the Federal Reserve Bank described 
in section 7.1 (Maintenance of Reserve Bank Accounts) 
is open, settlement will occur on the scheduled date, 
unless the RDFI has previously advised the Federal 
Reserve Bank that settlement for the entry should be 
deferred until the next banking day. If the RDFI has 
provided such notice to the Federal Reserve Bank, 
settlement for the debit entry will occur on the next 
banking day, and the RDFI shall pay the float charge 
assessed by the Federal Reserve. 
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SECTION 7.6 Effect of QPFI Closing on Time of 
Settlement 

If the scheduled Settlement Date for a credit entry is not 
a banking day for the ODFI but is a day on which the 
applicable office of the Federal Reserve Bank described 
in section 7.1 (Maintenance of Reserve Bank Accounts) 
is open, settlement will occur on the scheduled date. 



ARTICLE EIGHT - RECALL, 
STOP PAYMENT, RECREDIT, 
AND ADJUSTMENT 

SECTION 8.1 Recall by ODFI or Originator 

Except as allowed by sections 2.4 (Reversing Files), 2.5 
(Reversing Entries), and 2.6 (Reclamation Entries), 
neither an Originator nor an ODFI has the right to recall 
an entry or file, to require the return of or adjustment to an 
entry, or to stop the payment or posting of an entry, once 
the entry or file has been received by the Originating ACH 
Operator. 



SECTION .8,4 
Accounts 



Sto p Payment Affecting Consumer 



SECTION 8.2 ODFI Request for Return 

An ODFI may, orally or in writing, request an RDFI to 
return or adjust an erroneous entry initiated by the ODFI. 
For purposes of this section 8.2, an erroneous entry is an 
entry ( 1 ) that is a duplicate of an entry previously initiated 
by the Originator or ODFI, (2) that orders payment to or 
from a Receiver not intended to be credited or debited by 
the Originator, or (3) that orders payment in an amount 
different than was intended by the Originator. The RDFI 
may, but is not obligated to, comply with such a request. 
The ODFI making such a request indemnifies the RDFI 
from and against any and all claim, demand, loss, liability 
or expense, including attorneys' fees and costs, resulting 
directly or indirectly from compliance by the RDFI with 
such request. 

SKCTFON 8.3 ODFI Agrees to Accept CCD or CTX 
Return 

If an RDFI receives written notification from a Receiver 
after the time for return has expired (see Article Six, 
section 6.1 ' - Return of Entries) that a CCD or CTX debit 
entry to the Receiver's account was, in whole or in part, 
not authorized by the Receiver, the RDFI may transmit a 
permissible return entry to the ODFI, provided that the 
ODFI agrees, either verbally or in writing, to accept the 
late return entry. The permissible return entry must be in 
the amount of the debit entry and must comply with the 
requirements of Article Six, section 6,1 and Appendix 
Five (Return Entries). 



For all entries except ARC entries, RCK entries, POP 
entries; Single-Entry WEB entries, and TEL entries, a 
Receiver may stop the payment of a debit entry initiated 
or to be initiated to a Consumer Account of the Receiver 
by providing either verbal or written notification to the 
RDFI at least three banking days before the scheduled 
date of the transfer/An RDFI may honor a stop payment 
order received within the three-banking-day limit 
prescribed above, and, if it honors such a request, the 
RDFI has no resultant liability or responsibility to any 
Originator, ODFI, or other person having any interest in 
the entry. For ARC entries, for RCK entries, for POP 
entries, for Single-Entry WEB entries, and for TEL 
entries, the stop payment order must be provided to the 
RDFI at such time and in such manner as to allow the 
RDFI a reasonable opportunity to act upon the stop 
payment order prior to acting on the debit entry. The 
RDFI may require that written confirmation of a verbal 
stop payment order be made within 14 days of a verbal 
stop payment order, provided that the RDFI notifies the 
Receiver of this requirement and provides an address to 
which the written confirmation should be sent at the time 
the verbal order is provided. If the RDFI requires written 
confirmation, the verbal stop payment order will cease to 
be binding after 14 days. A Receiver may withdraw a 
stop payment order by providing written notice to the 
RDFI. A stop payment order will remain in effect (1) for 
six months from the date of the stop payment order, (2) 
until payment of the debit entry has been stopped, or (3) 
until the Receiver withdraws the stop payment order, 
whichever occurs earliest. 

SECTION 8.5 Stop Payment Affecting No n- 
Consumer Accounts 

A Receiver may order its RDFI to stop the payment of any 
debit entry initiated or.to.be initiated to a non-Consumer 
Account of the Receiver. The stop payment order must be 
provided to the RDFI at such time and in such manner as 
to allow the RDFI a reasonable opportunity to act upon 
the stop payment order prior to acting on the debit entry. 
The RDFI is obligated to comply with a verbal stop 
payment order only for a period of fourteen calendar days 
unless the order is confirmed in writing within that 14-day 
period. A written stop payment order is effective for six 
months unless it is renewed in writing. 

SECTION 8.6 Receiver's Right to Recredit 

SUBSECTION R 6.1 Receiver's Right to Recredit 

For all consumer entries except ARC entries, POP entries, 
and RCK entries, an RDFI must promptly credit the 
amount of a debit entry to a Consumer Account of a 
Receiver if (1) the Receiver sends or delivers to the RDFI 
a written statement under penalty of perjury as described 
in subsection 8.6.5 (Receiver's Written Statement Under 
Penalty of Perjury) mat the debit entry was not authorized 
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by the Receiver, and (2) this written statement is sent or 
delivered to the RDFI within 15 calendar days from the 
date the RDFI sends or makes available to the Receiver 
information relating to the debit entry in accordance with 
♦ section 4.5 (Periodic Statements). [For all entries to a 
Consumer Account except ARC entries, POP entries, and 
RCK entries, an RDFI must promptly credit the amount 
of a debit entry to a Consumer Account of a Receiver if 
(I) the Receiver sends or delivers to the RDFI a written 
statement under penalty of perjury as described in 
subsection 8.6.5 (Receiver's Written Statement Under 
Penalty of Perjury) that the debit entry was not 
authorized by the Receiver, and (2) this written statement 
is sent or delivered to the RDFI within 15 calendar days 
from the date the RDFI sends or makes available to the 
Receiver information relating to the debit entry in 
accordance with section 4.5 (Periodic Statements).} 

SUBSECTION 8.6.2- Receiver's Right to Recredit for 
POP Entries 

For POP entries, an RDFI must promptly credit the 
amount of a debit entry to a Consumer Account of a 
Receiver if (1) the Receiver sends or delivers to the RDFI 
a written statement under penalty of perjury as described 
in subsection .8.6.5.2 (Receiver's Written Statement Under 
Penalty of Perjury for POP Entries) stating that (i) the 
debit entry was not authorized by the Receiver, (ii) the 
source document used for the debit entry was improper 
pursuant to subsection 3.8.1 (Source Documents), or (lii) 
the source document was presented for payment, and (2) 
this written statement is sent or delivered to the RDFI 
within 15 calendar days from the date the RDFI sends or 
makes available to the Receiver information relating to the 
debit entry in accordance with section 4.5 (Periodic 
Statements). 

SUBSECTION 8.6.3 Receiver's Right to Recredit for 
RCK Entries 

For RCK entries for which a stop payment order has been 
placed on the item to which the RCK entry relates, an 
RDFI must promptly credit the amount of the debit entry 
to the Consumer Account of the Receiver, provided the 
Receiver notifies the RDFI of the stop payment order 
within 15 calendar days from the date the RDFI sends or 
makes available to the Receiver information relating to the 
debit entry in accordance with section 4.5 (Periodic 
Statements). 

For RCK entries for which either (i) notice stating the 
terms of the re-presented check entry policy was not 
provided by the Originator in accordance with subsection 
3.6.2 (Notice Obligation), (ii) the item to which the RCK 
entry relates is not an eligible item, (iii) all signatures on 
the item to which the RCK entry relates are not authentic 
or authorized, or the item to which the RCK entry relates 
has been altered, (iv) the amount of the RCK entry was 
not accurately obtained from the item, or (v) both the 
RCK entry and the item to which the RCK entry relates 
have been presented for payment, an RDFI must promptly 



credit the amount of the debit entry to a Consumer 
Account of the Receiver if (1) the Receiver sends or 
delivers to the RDFI a written statement under penalty of 
perjury as described in subsection 8.6.5.3 (Receiver's 
Written Statement Under Penalty of Perjury for RCK 
Entries) that either (i) notice stating the terms of the re- 
presented check entry policy was not provided by the 
Originator in accordance with subsection 3.6.2, (ii) the 
item to which the RCK entry relates is not an eligible 
item, (iii) all signatures on the item to which the RCK 
entry relates are not authorized or authentic, or the item to 
which the RCK entry relates has been altered, (iv) the 
amount of the RCK entry was not accurately obtained 
from the item, or (v) both the RCK entry and the item to 
which the RCK entry relates have been presented for 
payment, and (2) this written statement is sent or delivered 
to the RDFI within 15 calendar days from the date the 
RDFI sends or makes available to the Receiver 
information relating to the debit entry in accordance with 
section 4.5 (Periodic Statements). 

SUBSECTION 8.6.4 Receiver's Right to Recredit for 
ARC Entries 

For ARC entries for which a stop payment order has been 
placed on the source document to which the ARC entry 
relates, an RDFI must promptly credit the amount of the 
debit entry to the Consumer Account of the Receiver, 
provided the Receiver notifies the RDFI of the stop 
payment order within 15 calendar days from the date the 
RDFI sends or makes available to the Receiver 
information relating to the debit entry in accordance with 
section 4.5 (Periodic Statements). 

For ARC entries for which either (i) notice was not 
provided by the Originator in accordance with subsection 

3.7.1 (Notice Obligation), (ii) the source document used 
for the debit entry is improper pursuant to subsection 

3.7.2 (Source Documents), (iii) the source document was 
presented for payment, or (iv) the amount of the ARC 
entry was not accurately obtained from the source 
document, an RDFI must promptly credit the amount of 
the debit entry to a Consumer Account of the Receiver if 
( 1 ) the Receiver sends or delivers to the RDFI a written 
statement under penalty of perjury as described in 
subsection 8.6.5.1 (Receiver's Written Statement Under 
Penalty of Perjury for ARC Entries) that either (i) notice 
was not provided by the Originator in accordance with 
subsection 3.7.1, (ii) the source document used for the 
entry is improper, (iii) the source document was presented 
for payment, or (iv) the amount of the ARC entry was not 
accurately obtained from the source document, and (2) 
this written statement is sent or delivered to the RDFI 
within 15 calendar days from the date the RDFI sends or 
makes available to the Receiver information relating to the 
debit entry in accordance with section 4.5 (Periodic 
Statements); 
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£T TFtSFCTION 8.6.5 Receiver's Written Statement Under 
Penalty of Perjury 

For all consumer entries other than ARC entries, POP 
entries, or RCK entries, a Receiver must sign or similarly 
authenticate a written statement under penalty of perjury, 
in the form required by the RDFI, mat the debit entry for 
which the Receiver is seeking recredit under this section 
f 8.6 was not authorized by the Receiver. [For all entries to 
a Consumer Account other than ARC entries, POP 
entries, or RCK entries, a Receiver must sign or similarly 
authenticate a written statement under penalty of perjury, 
in the form required by the RDFI, that the debit entry for 
which the Receiver is seeking recredit under this section 
8 6 was not authorized by the Receiver.] 

SUBSECTION 8.6.5.1 Receiver's Written Statement 
Under Penalty of Perjury for ARC Entries 

For ARC entries for which a Receiver is seeking recredit, 
the Receiver must execute a written statement under 
penalty of perjury, in the form required by the RDFI, 
declaring and swearing under oath that either (i) notice 
was not provided by the Originator in accordance with 
subsection 3.7.1 (Notice Obligation), (ii) the source 
document used for the debit entry is improper pursuant to 
subsection 3.7,2 (Source Documents), (iii) the source 
document was presented for payment, or (iv) the amount 
of the ARC entry was not accurately obtained from the 
source document 

WmSFrTTON 8 6.5.2 Receiver's Written Statement 
Under Penalty of Perjury for POP Entries 

For POP entries for which a Receiver is seeking recredit, 
a Receiver must execute a written statement under penalty 
of perjury, in the form required by the RDFI, declaring 
and swearing under oath that either (i) the debit entry for 
which the Receiver is seeking recredit was not authorized 
by the Receiver, (ii) the source document used for the 
debit entry is improper pursuant to subsection 3.8.1 
(Source Documents), or (iii) the source document was 
presented for payment. 

SUBSECTION 8.6.5 .3 Receiver's Written Statement 
Under Penalty of Perjury for RCK Entries 

For RCK entries for which a Receiver is seeking recredit, 
the Receiver must execute a written statement under 
penalty of perjury, in the form required by the RDFI, 
declaring and swearing under oath that either (i) notice 
stating the terms of the re-presented check entry policy 
was not provided by the Originator, (ii) the item to which 
the RCK entry relates is not eligible pursuant to 
subsection 2.8,2 (Eligible Item), (iii) all signatures on the 
item to which the RCK entry relates are not authorized or 
authentic/or the item to which the RCK entry relates has 
been altered, (iv) the amount of the RCK entry was not 
accurately obtained from the item, or (v) both the RCK 
entry and the item to which the RCK entry relates have 
been presented for payment 



SUBSECTION 8.6.6 Unauthorized Debit Entry 

For purposes of this section 8.6, a debit entry was not 
authorized by the Receiver if (1) the authorization 
requirements of subsection 2.1 .2 (Receiver Authorization 
and Agreement) have hot been met; (2) the debit entry 
was initiated in an amount greater than that authorized by 
the Receiver; or (3) the debit entry was initiated for 
settlement earlier than authorized by the Receiver. An 
unauthorized debit entry does not include a debit entry 
initiated with fraudulent intent by the Receiver or any 
person acting in concert with the Receiver. 

STTRSF.CTION 8.6.7 Waiver of Right to Recredit 

An Originator may request a Receiver to waive the 
Receiver's rights under subsection 4.4.5 (Rights of 
Receiver Upon Unauthorized Debit to Its Account) with 
respect to one or more specific debit entries initiated to 
the Receiver's account. This waiver must ( 1 ) be in writing 
in a document entitled "WAIVER WITH RESPECT TO 
PRE-ARRANGED DEBIT", (2) specify the amount of 
each entry to which the waiver applies, (3) specify the 
approximate date on which each entry was initiated by the 
Originator, (4) specify the Originator number designated 
in each entry, and (5) specifically state in substance that 
the Receiver waives any right to have a designated RDFI 
credit the amount of the entry or entries to the Receiver's 
account due to error, unless the error was made by the 
RDFI. Except for waivers complying with the 
requirements of this subsection 8.6.7, no waiver by a 
Receiver of rights provided in subsection 4.4 .5 is effective 
for any purpose. If the ODFI and RDFI are parties to an 
agreement (other than these rules) for the provision of 
services relating to MTE or SHR entries, this subsection 
does not apply to such entries. 

SUBSECTION 8.6:8 Effect of Execution of Waiver 

If a waiver complying with the requirements of subsection 
8.6.7 (Waiver of Right to Recredit) has been signed by the 
Receiver and received by the RDFI in sufficient time and 
in such manner as to afford the RDFI a reasonable 
opportunity to act upon it, subsections 8.6.1 (Receiver's 
Rightto Recredit), 8.6.2 (Receiver's Rightto Recredit for 
POP Entries), 8.6.3 (Receiver's Right to Recredit for 
RCK Entries), 8.6.4 (Receiver's Right to Recredit for 
ARC Entries), 8.6,5 (Receiver's Written Statement Under 
Penalty of Perjury), and section 8.7 (Adjustment Entries) 
shall not apply to the entry or entries to which the waiver 
relates. If an Originator transmits such a waiver, with a 
copy, to an RDFI, the RDFI, upon written request of the 
Originator, must acknowledge receipt on the copy of the 
waiver and promptly deliver or send that copy to the 
Originator. 

ST m SECTION 8.6.9 Recredit Right Not Exclusive 

The rights provided to the Receiver under this section 8.6 
are in addition to any rights provided under Regulation E 
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of the Board of Governors of the Federal Reserve System 
or other applicable law. 

SECTION 8.7 Adjustment Entries 

SUBSECTION 8.7.1 RDFI's Right to Adjustment 

For all consumer entries except ARC entries, POP entries, 
and RCK entries, an RDFI receiving the written statement 
under penalty of perjury described in subsection 8.6.5 
(Receiver ' s Written Statement Under Penalty of Perjury) 
may transmit an adjustment entry to its ACH Operator in 
the amount of the unauthorized entry referred to hi the 
written statement under penalty of perjury, provided that 
(1) no error was made by the RDFI in the debiting of the 
entry to the Receiver's account, (2) the written statement 
under penalty of perjury described in subsection 8.6.5 was 
sent or delivered to the RDFI, and (3) the RDFI 
transmitted the adjustment entry to its ACH Operator by 
its deposit deadline for the adjustment entry to be made 
available to the ODFI no later than the opening of 
business on the banking day following the sixtieth 
calendar day following the Settlement Date of the original 
$ entry. [For all entries to a Consumer Account except ARC 
entries, POP entries, and RCK entries, an RDFI receiving 
the written statement under penalty of perjury described 
in subsection 8.6 5 (Receiver's Written Statement Under 
Penalty of Perjury) may transmit an adjustment entry to 
itsACH Operator in the amount of the unauthorized entry 
referred to in the written statement under penalty of 
perjury, provided that (1) no error was made by the RDFI 
in the debiting of the entry to th e Receiver 's acco unt, (2) 
the written statement under penalty of perjury described 
insubsection 8.6.5 was sent or delivered to the RDFI and 
(3) the RDFI transmitted the adjustment en try to its A CH 
Operator by its deposit deadline for the adjustment entry 
to be made available to the ODFI no later than the 
opening of business on the banking day following the 
sixtieth calendar day following the Settlement Date of the 
original entry.} The adjustment entry must comply with 
the requirements of section 6. 1 (Return of Entries) and 
Appendix Five (Return Entries). An RDFI may consider 
a written statement under penalty of perjury as timely if, 
in its reasonable judgment, the written statement under 
penalty of perjury appears to have been sent within the 
time limits described above. 

SUBSECTION 8.7.2 RDFI's Right to Adjustment for 
POP Entries 

For POP entries (i) that are unauthorized, (ii) for which 
the source document for the debit entry is improper 
pursuant to subsection 3.8. 1 (Source Documents), or (iii) 
for which the source document was presented for 
payment, an RDFI receiving the written statement under 
penalty of perjury described in subsection 8.6.5.2 
(Receiver's Written Statement Under Penalty of Perjury 
for POP Entries) may transmit an adjustment entry to its 
ACH Operator in the amount of the unauthorized entry 
referred to in the written statement under penalty of 
perjury, provided that ( 1 ) no error was made by the RDFI 



in the debiting of the entry to the Receiver's account, (2) 
the written statement under penalty of perjury described 
in subsection 8.6.5.2 was sent or delivered to the RDFI, 
and (3) the RDFI transmitted the adjustment entry to its 
ACH Operator by its deposit deadline for the adjustment 
entry to be made available to the ODFI no later than the 
opening of business on the banking day following the 
sixtieth calendar day following the Settlement Date of the 
original entry. The adjustment entry must comply with 
the requirements of section 6.1 (Return of Entries) and 
Appendix Five (Return Entries). An RDFI may consider 
a written statement under penalty of perjury as timely if, 
in its reasonable judgment, the written statement under 
penalty of perjury appears to have been sent within the 
time limits above. 

SUBSECTION 8.7.3 RDFI's Right to Adjustment for 
RCK Entries 




(I)- 



(2) 



For RCK entries for which a stop payment order 
has been placed on the item to which the RCK 
entry relates, an RDFI may transmit an 
adjustment entry to its ACH Operator in the 
amount of the RCK entry provided that the RDFI 
transmitted the adjustment entry to its ACH 
Operator by its deposit deadline for the 
adjustment entry to be made available to the 
ODFI no later than the opening of business on 
the banking day following the sixtieth calendar 
day following the Settlement Date of the RCK 
entry. The adjustment entry must comply with 
the requirements of section 6. 1 (Return of 
Entries) and Appendix Five (Return Entries). 

For RCK entries (i) for which the Originator did 
not provide notice that clearly and conspicuously 
stated the terms of the re-presented check entry 
policy in advance of receiving the item to which 
the RCK entry relates, (ii) that are not eligible 
pursuant to subsection 2.8.2 (Eligible Item), (iii) 
for which all signatures on the item to which the 
RCK entry relates are not authentic or 
authorized, or the item to which the RCK entry 
relates has been altered, (iv) for which the 
amount of the RCK entry was not accurately 
obtained from the item, or (v) both the RCK 
entry and the item to which the RCK entry 
relates have been presented for payment, an 
RDFI receiving the written statement under 
penalty of perjury described in subsection 
8.6.5.3 (Receiver's Written Statement Under 
Penalty of Perjury for RCK entries) may transmit 
an adjustment entry to its ACH Operator in the 
amount of the RCK entry referred to in the 
written statement under penalty of perjury, 
provided that (i) no error was made by the RDFI 
in the debiting of the entry to the Receiver's 
account, (ii) the written statement under penalty 
of perjury described in subsection 8.6.5.3 was 
sent or delivered to the RDFI, and (iii) the RDFI 
transmitted the adjustment entry to its ACH 
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Operator by its deposit deadline for the 
adjustment entry to be made available to the 
ODFI no later than the opening of business on 
me banking day following the sixtieth calendar 
day following the Settlement Date of the RCK 
entry. The adjustment entry must comply with 
the requirements of section 6.1 (Return of 
Entries) and Appendix Five (Return Entries). 
An RDFI may consider a written statement under 
penally of perjury as timely if, in its reasonable 
judgment, the written statement under penalty of 
perjury appears to have been sent within the time 
limits described above. 

SUBSECTION 8.7.4 RPFFs Right to Adjustment for 
ARC Entries 

(1) For ARC entries for which a stop payment order 
has been placed on the source document to 
which the ARC entry relates, an RDFI may 
transmit an adjustment entry to its ACH 
Operator in the amount of the ARC entry 
provided that the RDFI transmitted the 
adjustment entry to its ACH Operator by its 
deposit deadline for the adjustment entry to be 
made available to the ODFI no later than the 
opening of business on the banking day 
following the sixtieth calendar day following the 

- Settlement Date of the ARC entry. The 
adjustment entry must comply with the 
requirements of section 6. 1 (Return of Entries) 
and Appendix Five (Return Entries). 

(2) For ARC entries (i) for which the Originator did 
not provide notice in accordance with subsection 
3.7.1 (Notice Obligation), (ii) the source 
document used for the debit entry is improper 
pursuant to subsection 3.7.2 (Source 
Documents), (iii) the source document was 
presented for payment, or (iv) the amount of the 
ARC entry was not accurately obtained from the 
source document, an RDFI receiving the written 
statement under penalty of perjury as described 
in subsection 8.6.5.1 (Receiver's Written 
Statement Under Penalty of Perjury for ARC 
Entries) may transmit an adjustment entry to its 
ACH Operator in the amount of the ARC entry 
referred to in the written statement under penalty 
of perjury, provided that (a) no error was made 
by the RDFI in the debiting of the entry to the 
Receiver's account, (b) the written statement 
under penalty of perjury described in subsection 
8.6.5.1 was sent or delivered to the RDFI, and 
(c) the RDFI transmitted the adjustment entry to 
its ACH Operator by its deposit deadline for the 
adjustment entry to be made available to the 
ODFI no later than the opening of business on 
the banking day following the sixtieth calendar 
day following the Settlement Date of the ARC 
entry. The adjustment entry must comply with 
the requirements of section 6.1 (Return of 



Entries) and Appendix Five (Return Entries). 
An RDFI may consider a written statement under 
penalty of perjury as timely if, in its' reasonable 
judgment, the written statement under penalty of 
perjury appears to have been sent within the time 
limits described above. 

SUBSECTION 8.7.5 Warranty of RDFI 

Each RDFI transmitting an adjustment entry pursuant to 
subsection 8.7. 1 (RDFI's Right to Adjustment), 8.7.2 
(RDFI's Right to Adjustment for POP Entries), 8.7.3(2) 
(RDFFs Right to Adjustment for RCK Entries), and 
8.7.4(2) (RDFI's Right to Adjustment for ARC Entries) 
warrants to each ODFI, ACH Operator, and Association 
that, prior to initiating the adjustment entry, the RDFI 
obtained from the Receiver a written statement under 
penalty of perjury complying with section 8.6 (Receiver's 
Right to Recredit). Each RDFI breaching this warranty 
shall indemnify every ODFI, ACH Operator, and 
Association from and against any and all claim, demand, 
loss, liability, or expense, including attorneys' fees and 
costs, resulting directly or indirectly from the breach of 
such warranty. 

SUBSECTION 8.7.6 Copy of Written Statement Under 
Penalty of Perjury 

Each RDFI initiating an adjustment entry pursuant to 
subsection 8.7.1 (RDFI's Right to Adjustment), 8.7.2 
(RDFI's Right to Adjustment for POP Entries), 8.7.3(2) 
(RDFFs Right to Adjustment for RCK Entries), and 
8.7.4(2) (RDFI's Right to Adjustment for ARC Entries) 
shall send to the ODFI, within sixty (60) days after 
receiving a written request from the ODFI, a copy of the 
written statement under penalty of perjury obtained from 
the Receiver in accordance with section 8.6 (Receiver's 
Right to Recredit), provided such request is received by 
the RDFI within one year of the date of the initiation of 
the adjustment entry. 

SUBSECTION 8.7.7 Acceptance of Adjustment Entries 
bv ODFI 

Each ODFI must accept adjustment entries transmitted to 
it in accordance with these rules. 

SECTION 8.8 A pplication to MTE and SHREntries 

If the ODFI and RDFI are parties to an agreement (other 
than these rules) for the provision of services relating to 
MTE or SHR entries, sections 8.6 (Receiver's Right to 
Recredit) and 8.7 (Adjustment Entries) shall not apply to 
such entries. 
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ARTICLE NINE-OBLIGATIONS 

OF AUTOMATED CLEARING 
HOUSE OPERATORS 

SECTION 9.1 Processing Obligation 

Each ACH Operator must, in accordance with Appendix 
Two (ACH Record Format Specifications): 

(1) promptly process entries and entry data, insert the 
appropriate Settlement Date, and reject batches and files 
in accordance with section 9.3 (Return and Rejection by 
ACH Operator), 

(2) transmit or make available entries and entry data to 
the appropriate ACH Operator or Participating DFI in 
accordance with agreed upon processing and delivery 
schedules, 

(3) remake any file rejected by an ACH Operator 
pursuant to section 9.3 (Return and Rejection by ACH 
Operator), 

(4) remake any file rejected by an RDFI, 

(5) total the debit and credit activity received from and 
transmitted to each other ACH Operator and Participating 
DFI during each banking day, and 

(6) calculate the settlement amounts for each day for all 
entries processed under these rules. 

SECTION 9*2 Automated Accounting Advices 

An ACH Operator may provide ACH accounting 
information in machine readable format to facilitate the 
automation of accounting information for Participating 
DFIs. Accounting information shall be provided in 
standard record formats with specific field contents as 
mdiicated in Appendix Two (ACH Record Format 
Specifications). The ACH Operator will provide 
accounting information in a separate file. For Automated 
Accounting Advices, the ACH Operator is the Company 
as well as the ODFI. 



SECTION 9.3 
Operator 



Return and Rejection by ACH 



If an entry or entry data received by an ACH Operator for 
processing does not meet the acceptance criteria set forth 
in Appendix Two (ACH Record Format Specifications), 
Appendix Five (Return Entries), or Appendix Six 
(Notification of Change), the ACH Operator must in 
accordance with those Appendices either return the entry 
or entry data to the appropriate ACH Operator or ODFI or 
reject the entire batch or file containing the entry by 



notifying the appropriate ACH Operator or the ODFI (or 
its Sending Point). 

SECTION 9.4 Originator Status Code Review 

Each Originating ACH Operator must review each batch 
of entries it receives to ensure that the appropriate status 
code pertaining to the Originator (the "Originator Status 
Code") is included in accordance with Appendix Two 
(ACH Record Format Specifications). If a batch of 
entries contains an incorrect Originator Status Code or 
contains no Originator Status Code, the ACH Operator 
must either reject the batch or insert the correct Originator 
Status Code. 

SECTION 9.5 Optional Services 

An ACH Operator may provide optional services. The 
use of the optional services must not inconvenience or 
adversely affect the rights of other ACH Operators or 
Participating DFIs that do not use optional services. 

SECTION 9.6 Non-Settled Entries 

If a Participating DFI is unable to meet its settlement 
obligations under the settlement rules established by the 
Participating DFI and its ACH Operator for entries it has 
originated or received ("non-settled entries"), the ACH 
Operator must return or reverse the non-settled entries in 
accordance with sections 9.7 (Entries Originated to an 
RDFI that Cannot Settle) and 9.8 (Entries Received from 
an ODFI that Cannot Settle). Each ACH Operator is 
responsible for establishing the definition of non-settled 
entries and the procedures under which settlement 
balances are to be adjusted within its own settlement rules. 

SECTION 9.7 Entries Originated to an RDFI that 
Cannot Settle 

The ACH Operator must create a return entry complying 
with the requirements of Appendix Five (Return Entries) 
for each non-settled entry and transmit that non-settled 
entry to the ODFI. An ODFI that receives a return entry 
complying with the requirements of this section 9.7 must 
accept and may not dishonor that entry. The ODFI may 
not reinitiate a non-settled entry. 

SECTION 9.8 Entries Received from an ODFI that 
CannotSettle 

The ACH Operator must create a reversing entry 
complying with the requirements of Appendix Two (ACH 
Record Format Specifications) for each non-settled entry 
and transmit that non-settled entry to the RDFI. An RDFI 
that receives such a reversing entry complying with the 
requirements of this section 9.8 must accept and may not 
return that reversing entry. 
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SECTION- 9.9 Record of Entries 

Each ACH Operator must retain a record of all entries, 
return entries; and adjustment entries (all referred to in 
this section as "entries") received or transmitted by it for 
one year from the date of receipt or transmittal of the 
entry. The ACH Operator must provide a printout or 
other reproduction of the information relating to a 
particular entry if requested to do so by the Participating 
DFI or other ACH Operator that originated, transmitted, 
or received the entry. 

SECTION 910 Requirement to Provide Information 
to National Association 

Each ACH Operator will provide to the National 
Association monthly reports relating to return entry data, 
as specified by the National Association. 



ARTICLE TEN .-. CHECK 

TRUNCATION ENTRIES 



SECTION 10.1 Scope 



The rules contained within this Article Ten apply to all 
entries initiated under the rules of a check truncation 
program that uses the TRC or TRX Standard Entry Class 
Code (referred to as "program"). For this Article, "entry" 
refers to a demand for payment made upon an RDFI by an 
ODFI complying with the requirements of this Article. 

SECTION 10.2 Eligible Participants and Warranties 

An ODFI participating in a program must not transmit an 
entry subject to this section 10.2 to an RDFI unless the 
RDFI is a participant in the same program. Any 
participating ODFI that transmits an entry subject to this 
section 10.2 to an RDFI not participating in the program 
shall indemnify the RDFI from and against any and all 
claim, demand, loss, liability, or expense, including 
attorneys' fees and costs, resulting directly or indirectly 
from the debiting of the entry. An ODFI not participating 
in a program must not transmit an entry identified by the 
TRC or TRX Standard Entry Class Code to an RDFI. 
Any such non-participating ODFI that transmits such a 
TRC or TRX entry through an ACH Operator to an RDFI 
shall indemnify the RDFI from and against any and all 
claim, demand, loss, liability, or expense, including 
attorneys' fees and costs, resulting directly or indirectly 
from the debiting of the entry to the deposit account 
identified in the entry. 



SECTION 103 
Operator 



Return and Rejection by an ACH 



An Originating ACH Operator must reject any batch of 
entries identified by the TRC or TRX Standard Entry 



Class Code that is not originated by a participant in a 
program and must promptly notify the ODFI of such 
action. A Receiving ACH Operator must return any entry 
identified by the TRC or TRX Standard Entry Class Code 
if the RDFI is not a program participant. An ACH 
Operator shall determine whether an ODFI or RDFI is a 
participant in a program solely from the information 
provided to the ACH Operator by each program. 

SECTION 10.4 Format Specifications for "TRC" or 
"TRX"Entries 

Entries initiated under this Article Nine must be identified 
by the Standard Entry Class Code "TRC" or "TRX" and 
must comply with the requirements of Appendix Two 
(ACH Record Format Specifications). 

SECTION 10.5 A pplication of Rules to "TRC" or 

"TRX" Entries 

Unless otherwise provided for in the rules of a program, 
and with the exceptions listed below, these rules apply to 
all entries subject to this Article Ten. The following rules 
do not apply to such entries: 

1.7 (Choice of Law) 

2.1 (Prerequisites to Origination) 

2.2 (Warranties and Liabilities of ODFIs) 

2.3 (Prenotifications) 

2.5 (Reversing Entries) 

2.6 (Reclamation Entries) 

2.12 (Reinitiation ofReturned Entries by Originators) 
Article Three (Obligations of Originators) 

4. 1 . 1 (Right to Information Regarding Entries) 

4.1.2 (Obligation to Verify Prenotification) 

4.1.3 (Obligation to Accept Entries) 

4. 1 .4 (Reliance on Account Numbers for Posting of 
Entries) 

4.2 (Warranties of Receiving Depository Financial 
Institutions) 

4.4.1 (Availability of Credit Entries to Receivers) 

4.4.2 (Time of Debiting of Entries) 

4 .4 .4 (Crediting of Originators' Accounts by Receiver) 

4.4.5 (Rights ofReceiver Upon Unauthorized Debit to 
Its Account) 

4.4.7 (Reimbursement of RDFI) 

4.5 (Periodic Statements) 

4.6 (Notice to Receiver) 

4.8 (Liability of RDFI for Benefit Payments) 
Article Seven (Return, Adjustment, Correction, and 

Acknowledgment of Entries and Entry 
Information) 

7.4 (Accountability for Entries) 

8.3 (ODFI Agrees to Accept CCD or CTX Return) 

8.4 (Stop Payment Affecting Consumer Accounts) 

8.5 (Stop Payment Affecting Non-Consumer 
Accounts) 

8.6 (Receiver's Right to Recredit) 

8.7 (Adjustment Entries) 

8.8 (Application to MTE and SHR Entries) 
14.1.12 (definition of "Banking Day M ) 
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14.1.27- (definition of "File") 

14.1.41 (definition of 'Person") 

14.1.52 (definition of •'Send") 

Appendix Four (Minimum Description Standards) 

Appendix Five (Return Entries) 

Appendix Six (Notification of Change) 

Appendix Eight (Rule Compliance Audit Requirements) 

Appendix Nine (Compensation Rules) 

Appendix Ten (Arbitration Procedures) 

SECTION 10.6 Inconsistency Between Article Ten 
and Program Rules 

If there is an inconsistency between this Article Ten and 
the rules of a program, the program's rules govern. 



ARTICLE ELEVEN - 
GROSS-BORDER PAYMENTS 



SECTION 11.1 Scope 

The rules contained within this Article Eleven apply to all 
CBR and PBR entries and entry data transmitted through 
one or more ACH Operators in the United States. These 
rules provide that the U.S. segment of the cross-border 
entry shall be settled separately between the U.S. 
Participating DFI and the U.S. OGO or RGO. ODFIs are 
responsible for identifying and understanding the laws and 
payment system rules of foreign countries that are 
applicable to Outbound CBR and PBR entries that they 
originate. 

SECTION 11.2 Originator/ODFI Agreement 

Prior to the origination of Outbound CBR and PBR 
entries, each Originator, Third-Party Sender, and ODFI 
must specify in the agreement required by subsection 
2.1.1 (Originator Authorization and Agreement) (1) the 
terms and conditions for the allocation of gains, losses, 
and the assumption of risk for foreign exchange 
conversion, and (2) the rights and responsibilities of the 
ODFI in the event of error or duplicate entries. 

SECTION 113 QDFI/OGQ Agreement 

Prior to the origination of Outbound CBR and PBR 
entries, each ODFI must enter into an agreement with an 
OGO that (1) obligates the OGO to execute the cross- 
border transfer of funds in accordance with the Cross- 
Border Payment Operating Rules, as in effect from time 
to time, and (2) identifies the party that will assume the 
liability for the amount of all Outbound debit entries 
received that are not returned in accordance with the 
payment system rules of the receiving country. 



SECTION 1 1.4 ODFI Warranties for Outbound 
Cross-Border Entries 

In addition to the other warranties contained within these 
rules, each ODFI initiating an Outbound CBR or PBR 
entry warrants to each ACH Operator, OGO, and 
Association that: 

SUBSECTION 1 1 .4. 1 Compliance with Foreign Payment 
System Rules 

The origination of the CBR or PBR entry is in compliance 
with the laws and payment system rules of the receiving 
country. 

SUBSECTION 1 1.4.2 Termination of Agreement 

At the time a CBR or PBR entry is transmitted to an ACH 
Operator, the Originator's authorization has not been 
revoked, and the agreement between the ODFI and 
Originator concerning the entry has not been terminated. 

SUBSECTION 1 1.4.3 Information Conforms to 
Requirements 

Each entry transmitted by the ODFI to the ACH Operator 
contains the correct Receiver account number and the 
information transmitted with the entry is payment related 
and conforms to the requirements of Appendix Two (ACH 
Record Format Specifications). 

SUBSECTION 1 1.4.4 Liability for Breach of Warranty 

Each ODFI breaching any of the warranties contained 
within this section 1 1.4 (ODFI Warranties for Outbound 
Cross-Border Entries) shall indemnify every ACH 
Operator, OGO, and Association from and against any 
and all resulting claim, demand, loss, liability, or expense, 
including attorneys' fees and costs, resulting directly or 
indirectly from the breach of these warranties. 

SECTION 11 .5 OGO Warranties for Outbound 
Cross-Border Entries 




SUBSECTION 11 .5. 1 Compliance with Foreign Payment 
System Rules 

Each OGO that transmits a CBR or PBR entry to an RGO 
in another country warrants to each ODFI, ACH Operator, 
and Association that it has processed and edited such 
Outbound entry in a manner that is in compliance with the 
requirements set forth in the laws and payment system 
rules of the receiving country. 

SUBSECTION 1 1 .5.2 Compliance with Cross-Border 
Payment Operating Rules 

Each OGO that transmits a CBR or PBR entry to an RGO 
in another country warrants to each ODFI, ACH Operator, 
and Association that such Outbound entry is in 
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compliance with the requirements of the Cross-Border 
Payment Operating Rules. 

SUBSECTION 11.5.3 Liability for Breach of Warranty 

Each OGO breaching any of the warranties contained 
within this section 11. 5 (OGO Warranties for Outbound 
Cross-Border Entries) shall indemnify every ODFI, ACH 
Operator, and Association from and against any and all 
resulting claim, demand, loss, liability, or expense, 
including attorneys ' fees and costs, resulting directly or 
indirectly from the breach of these warranties. 

SECTION 11.6 RGO Warranties for Inbound Cross- 
Border Entries 

In addition to all warranties of an ODFI, the RGO, acting 
as an ODFI, makes the following additional warranties 
with respect to Inbound cross-border entries: 

SUBSECTION 1 1.6.1 OGO/RGO Agreement 

Each RGO warrants to each RDFI, ACH Operator, and 
Association that it has entered into an agreement with the 
OGO in the country in which the Inbound entry was 
originated and that the OGO has agreed that each Inbound 
entry it transmits will be in compliance with applicable 
U.S. law, the Cross-Border Payment Operating Rules, and 
these rules. 

SUBSECTION 1 1.6.2 Compliance with Cross-Border 
Payment Operating Rules 

Each RGO that transmits an Inbound CBR or PBR entry 
into the ACH network warrants to each RDFI, ACH 
Operator, and Association that such entry is in compliance 
with the requirements of the Cross-Border Payment 
Operating Rules. 

SUBSECTION 11.6.3 Liability for Breach of Warranty 

Each RGO breaching any of the warranties contained 
within this section 11.6 (RGO Warranties for Inbound 
Cross-Border Entries) shall indemnify every RDFI, ACH 
Operator, and Association from and against any and all 
resulting claim, demand, loss, liability, or expense, 
including attorneys' fees and costs, resulting directly or 
indirectly from the breach of these warranties . 

SECTION 11.7 OGO/RGO as Participating DFI 

SUBSECTION 11.7.1 OGO Acting as RDFI 

For purposes of these rules, each OGO that receives a 
CBR or PBR entry from an ODFI is deemed to have 
assumed the specific responsibilities and warranties of the 
RDFI with respect to the U.S. segment of each Outbound 
cross-border entry. The responsibilities and warranties of 
the RDFI are included in, but not limited to, Article Four 
(Receipt of Entries). 



SUBSECTION 1 1.7.2 RGO Acting as ODFI 

For purposes of these rules, each RGO that transmits a 
CBR or PBR entry to an RDFI is deemed to have assumed 
the specific responsibilities and warranties of the ODFI 
with respect to the U.S. segment of each Inbound cross- 
border entry. 

SECTION 11.8 Dishonor of Return by QDFI 

An ODFI may dishonor a return entry if (1) the payment 
system rules of the receiving country of the original 
Outbound cross-border entry permit the dishonor of a 
return entry, and (2) the return does not comply with the 
payment system rules of the receiving country of the 
original Outbound cross-border entry, or the return 
contains incorrect information, does not include all 
information required by Appendix Five (Return Entries), 
or otherwise fails to comply with the requirements of 
Appendix Five. To dishonor a return entry, the ODFI 
must (1) transmit a dishonored return entry in accordance 
with the provisions of Appendix Five, and (2) transmit the 
dishonored return entry to its ACH Operator within five 
banking days of the settlement date of the return entry. 

SECTION 11.9 A pplication of Rules to Cross-Border 
Entries 

SUBSECTION 11.9.1 Application of Rules 

With the exceptions listed below, these rules apply to all 
cross-border entries subject to this Article Eleven. 

SUBSECTION 1 1 .9.2 Exceptions for Outbound Cross- 
Border Entries 

The following rules do not apply to Outbound (i.e., 
originated in the United States and transmitted to another 
country) cross-border entries: 



2.1.2 
2.2. LI 
2.2.1.4 
2.2.1.5 

2.2.1.9 

2.2.1.10 

2.3 

2.4 

2.5 

2.6 

2.12 

3.4 

3.5 

3.12 
4.1 
4.3 
4.4 



Receiver Authorization and Agreement 

Authorization by Originator and Receiver 

Revocation of Authorization 

Termination of Authorization by Operation of 

Law 

Transmittal of Required Information 

Reclamation Entries 

Prenotifications 

Reversing Files 

Reversing Entries 

Reclamation Entries 

Reinitiation of Returned Entries by Originators 

Consumer Accounts— Notice by Originator to 

Receiver of Variable Debits 

Consumer Accounts - Copy of Debit 

Authorization 

Record of Authorization 

General Rights and Obligations of RDFI 

Receipt and Availability of Entries 

Availability of Entries and Entry Information, 

Crediting and Debiting of Entries 
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4.5 Periodic Statements 

4.6 Notice to Receiver 

4.8 Liability of RDFI for Benefit Payments 

6.1 Return of Entries 

6.2 Dishonor of Return Entries 

6.3 Notification of Change 

7.4 Accountability for Entries 

8.4 Stop Payment Affecting Consumer Accounts 

8.5 Stop Payment Affecting Non-Consumer 
Accounts 

8.6 Receiver's Right to Recredit 

8.7 Adjustment Entries 

Appendix Four Minimum Description Standards 

SUBSECTION 11 .9.3 RDFFs Right to Return Outbound 
Cross-Border Entries 

For purposes of the rules contained within this Article 
Eleven, an OGO acting as an RDFI for an Outbound 
cross-border entry has the right to return a credit, debit, or 
zero-dollar entry if the OGO determines that the 
processing of such entry will expose the OGO to 
excessive risk. 

SUBSECTION 1 1 .9.4 Receipt and Availability of Entries 

An Outbound cross-border entry is deemed received by 
the OGO acting as an RDFI on the banking day on which 
the entry or entry data is made available to it or to a 
Receiving Point used by the RDFI. 



ARTICLE TWELVE - 
REQUIREMENTS 
OF ASSOCIATIONS 

SECTION 12.1 Warranties of Associations 

Each Association represents and warrants the following to 
each other Association and each Participating DFI of such 
other Association: 



SUBSECTION 12.1.1 
Transmit Entries 



Members' Authorization to 



At the time an entry (or related data) is transmitted, each 
of the Association's members and each person authorized 
by the Association to transmit the entry (or related data) 
to an ACH Operator is a Participating DFI and bound by 
these rules as then in effect. 



SUBSECTION 12.1.2 
Receive Entries 



Members' Authorization to 



(or related data) directly or indirectly from an ACH 
Operator is a Participating DFI and bound by these rules 
as then in effect. 

SUBSECTION 12.1.3 Obligations Upon Resignation of 
Members 

A Participating DFI's resignation of membership or any 
event terminating a Participating DFFs membership does 
not affect the Participating DFFs obligations under these 
rules resulting from any transaction that occurred prior to 
the resignation or other event terminating membership. 

SUBSECTION 12.1.4 ACH Operator Indemnity of 
Association 

Each ACH Operator (other than a Federal Reserve Bank) 
that has contracted with an Association to provide 
Automated Clearing House services has agreed (1) to 
indemnify the Association against any damages resulting 
from the negligence or willful misconduct of the ACH 
Operator, its agents, or its employees, and (2) that the 
measure of damages provided by the contract is not less 
than the measure of damages for which the Association is 
liable to a Participating DFI under section 12.3 
(Association Liability for Negligence and Willful 
Misconduct ofits ACH Operator). This subsection 12.1.4 
does not apply to the extent that the contract provides that 
the ACH Operator (1) is not liable to the Association, or 
(2) is entitled to reimbursement for any payment made to 
or for the benefit of any Participating DFI which unjustly 
enriches the Participating DFI. 




At the time an entry (or related data) is received or 
transmitted, each of the Association's members and each 
person authorized by the Association to receive the entry 



SUBSECTION 12.1 .5 Liability for Breach of Warranty 

Any Association that breaches any of the representations 
and warranties contained in this section 12. 1 shall 
indemnify each other Association and Participating DFI 
of the other Association from and against any and all 
claim, demand, loss, liability, or expense, including 
attorneys' fees and costs, resulting directly or indirectly 
from the breach or from the fact that any matter is not as 
represented and warranted by the warranting Association. 

SECTION 12.2 Requirements to Provide Information 
to National Association 

If requested to do so by the National Association, each 
Association must provide the National Association with 
information relating to matters warranted in section 12.1 
(Warranties of Associations). 

SECTION 12.3 Association Liability for Negligence 
and Willful Misconduct of its ACH Operator 

Each Association is liable to each Participating DFI and 
each other Association for (1) its negligence and willful 
misconduct related to its functioning as an ACH Operator, 
and (2) for the negligence and willful misconduct of each 
ACH Operator (other than a Federal Reserve Bank) with 
which the Association has contracted to provide services 
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to Participating DFIs. The measure of damages with 
respect to a credit entry (including a return credit entry) is 
limited to damages attributable directly and immediately 
to the failure to exercise ordinary care or to willful 
misconduct. These damages do not include damages that 
are attributable to the consequences of the conduct, even 
if such consequences were foreseeable at the time of the 
conduct. The measure of damages with respect to a debit 
entry (including a return debit entry or a debit entry 
adjustment) is the amount of the entry reduced by an 
amount that could not have been realized by the use of 
ordinary care. Where there is willful misconduct with 
respect to a debit entry, the measure of damages includes 
other damages that are attributable directly and 
immediately to the willful misconduct, but does not 
include damages that are attributable to the consequences 
of the misconduct, even if such consequences were 
foreseeable at the time of the misconduct. The measure of 
damages for failure to exercise ordinary care or willful 
misconduct with respect to a prenotification, a return entry 
relating to a prenotification, a notification of change or 
other notice is limited to the amount of the fee received by 
such Association or ACH Operator for the notice. For 
this section 12.3, negligence and willful misconduct of an 
Association or an ACH Operator includes the negligence 
or willful misconduct of its officers or employees. 

SECTION 12.4 Protection for the National 
Association from Frivolous Lawsuits 

Each Participating DFI which commences a legal 
proceeding against the National Association shall pay on 
demand the attorneys' fees and costs incurred by the 
National Association in connection with the proceeding if 
judgment is rendered in the National Association's favor 
or if the National Association is otherwise dismissed from 
the proceeding. 

SECTION 12.5 ACH Operator Not Agent of 
Participating DFI . 

An ACH Operator is not an agent of a Participating DFI. 
In the case of a credit entry subject to Article 4 A, where 
the terms of the entry originated by the ODFI differ from 
the terms of the entry received by the RDFI, the ODFI 
shall be obligated for the entry it originated. This rule 
shall not affect the liability of an Association or an ACH 
Operator as otherwise provided in these rules. 



ARTICLE THIRTEEN - 
AMENDMENT OF THE RULES 



SECTION 13.1 Procedures for Amendment of the 
Rules 



Any amendment (including any addition to or repeal) of 
these rules may be made by the vote by ballot without a 



meeting of at least two-thirds of the voting power cast on 
the amendment by the members entitled to vote on such 
matters, as defined in Article VI of the By-Laws of the 
National Association, In accordance with Article VI of 
the By-Laws of the National Association, members 
entitled to vote on such matters are: (1) Direct Financial 
Institution members; and (2) Payment Association 
members. Any such amendment shall be submitted to the 
voting members by mail, fax, or e-mail at le as t 1 5 
business days prior to the close of the balloting period for 
such amendment. Each amendment shall become 
effective on the date indicated in the ballot or vote relating 
to the amendment. 

SECTION 13.2 Temporary Adoption, Suspension; or 
Change of Implementation Date of Rules 

The Board of Directors of the National Association may 
approve, suspend, or change the implementation date of 
a rule if it determines such action is in the best interests of 
the National Association and its members. Any action 
taken by the Board of Directors pursuant to this section 
shall remain effective until action on the rule approved, 
suspended, or whose implementation date was changed by 
the Board of Directors is taken in accordance with section 
13.1 (Procedures for Amendment of the Rules). 



ARTICLE FOURTEEN - 
DEFINITION OF TERMS 

SECTION 14.1 Definitions As Used In These Rules 

SUBSECTION 14.1.1 " ACH Operator " or " Automated 
Clearing House Operator " 

means (1) a Federal Reserve Bank that performs all of the 
following, or (2) an entity that executes an annual 
agreement with the National Association in which the 
entity agrees to comply with or perform all of the 
following: 

adhere to these rules (except to the extent 
inconsistent with the policies or practices of the 
Federal Reserve Banks) and other applicable 
laws, regulations, and policies; 
■•■■'. V . execute agreements with a minimum of twenty 
independent (i.e., not owned by the same holding 
company) Participating DFIs that bind such 
entities to the ACH Operator's rules and to these 
rules (except that a Federal Reserve Bank shall 
not be required to bind a Participating DFI to 
any provision of such rules of the National 
Association that is not incorporated by the 
Uniform Operating Circular of the Federal 
Reserve Banks); 
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■ •■ . (1) provide clearing, delivery, and settlement 

services for ACH entries, as defined by these 
rules, between Participating DFIs that have 
selected that ACH Operator to perform ACH 
services (intra- ACH Operator services), and (2) 
exchange transactions with other ACH Operators 
(inter- ACH Operator exchange); 

• " ■ process and edit files based on the requirements 

of these rules; 

evaluate the credit worthiness of and apply risk 
control measures to their Participating DFIs; 
'•'■■: ■'■;'■' . adhere to the Federal Reserve's Policy Statement 
on Privately Operated Multilateral Settlement 
Systems (as applicable); and 

• .■■■■.'■■ adhere to any National ACH Operator 

Performance Standards of the National 
Association. 

SUBSECTION 14. 1 .2 " ACK Entry " or "ACK" 

means an entry which provides an acknowledgment of 
receipt by the RDFI of a corporate credit payment 
originated using the CCD format. An ACK entry may be 
accompanied by one addenda record which relays 
information about the financial EDI credit payment using 
the ANSI ASC X12 REF (Reference) data segment. 

SUBSECTION 14.1.3 ' Alphameric " 

means any character - 9, A - Z, blank, and printable 
special characters which have an EBCDIC value greater 
than hexadecimal 3F. Fields defined in these Rules as 
"alphameric" may contain any of these allowable 
characters. 

SUBSECTION 14. 1 .4 " ANSI ASC X12.5 " (Interchange 
Control Structure) 



means the standard to define the control structures for the 
electronic interchange of business transactions encoded in 
ASC X 1 2-based syntax. This standard provides the 
interchange envelope of a header and trailer for the 
electronic interchange through a data transmission, a 
structure to acknowledge the receipt and processing of 
this envelope, and optional, interchange-level service 
request structures. 

SUBSECTION 14.1.5 " ANSI ASC X12.6 " (Application 
Control Structure) 

means the standard used to define the structure of business 
transactions for computer-to-computer interchange. This 
structure is expressed using a symbolic representation of 
X12 data in terms of both the design and use of XI 2 
structures, independent of the physical representation 
(e.g., character set encoding). 

SUBSECTION 14.1.6 " ARC entry " 



means a Single Entry debit initiated by an Originator to a 
Consumer Account of the Receiver pursuant to a source 



document, as set forth in subsection 2.9.1 (Source 
Documents), provided to the Originator by the Receiver 
via the U.S. mail or at a dropbox location. 

SUBSECTION 14.1.7 " Article 4A " 

means Article 4A of the Uniform Commercial Code as 
enacted in the State of New York. 

SUBSECTION 14.1.8 "Association" 



means any member of the National ACH Association. 

SUBSECTION 14.1.9 " ATX entry " or "ATX" 

means an entry which provides an acknowledgment of 
receipt by the RDFI of a corporate credit payment 
originated using the CTX format. An ATX entry may be 
accompanied by one addenda record which relays 
information about the financial EDI credit payment using 
the ANSI ASC X12 REF (Reference) data segment. 

SUBSECTION 14.1.10 " Automated Clearing House " or 
"ACH" 

means a funds transfer system governed by the Rules of 
the National Automated Clearing House Association 
which provides for the interbank clearing of electronic 
entries for participating financial institutions. 

SUBSECTION 14.1.1 1 " BPR or BPS Data Segment " or 
" Beginning Segment for Payment Order/Remittance 
Advice " 

means the beginning segment for the payment 
order/remittance advice used in ASC XI 2-based syntax to 
indicate the beginning of a payment-related transaction set 
which contains the necessary banking information to 
process the transaction. 

SUBSECTION 14.1.12 " Banking Day " 

means, with reference to a Participating DFI, any day on 
which such DFI is open to the public during any part of 
such day for carrying on substantially all of its banking 
functions, and, with reference to an ACH Operator, any 
day on which the appropriate facility of such ACH 
Operator is being operated. 

SUBSECTION 14.1.13 " Business Day " 

means a calendar day other than a Saturday, Sunday, or 
Federal holiday. 

SUBSECTION 14.1.14 " CBR entry " 

means a credit or debit entry initiated to effect a payment 
exchanged between payment system participants of 
different countries, via an Originating Gateway Operator 
and a Receiving Gateway Operator, to or from a corporate 
account of the Receiver. 
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SUBSECTION 14.1.15 " CCD entry " 

means a credit or debit entry initiated by an organization 
to consolidate funds of that organization from its 
branches, franchises or agents, or from other 
organizations, or to fund the accounts of its branches, 
franchises or agents, or of another organization. "CCD+" 
is a CCD entry with one addenda record. 

SUBSECTION 14.1.16 " CIE entry " or "CIE" 

means a credit entry initiated by or on behalf of the holder 
of a Consumer Account to effect a transfer of funds to the 
account of the Receiver. "CIE+" is a CIE entry with one 
addenda record. 

SUBSECTION 14. 1. 17 " Consumer Account " 

means an account held by a Participating DFI and 
established by a natural person primarily for personal, 
family or household and not for commercial purposes. 

SUBSECTION 14.1.18 " CTX entry " 

means a credit or debit entry initiated by an organization 
to effect a transfer of funds to or from the account of that 
organization or another organization and accompanied by 
addenda records that relay information formatted in 
accordance with the ANSI ASCX12. 5 and X12.6 syntax, 
an ASC X12 transaction set containing a BPR or BPS 
data segment, or payment related UN/EDIF ACT syntax. 
A CTX entry can contain up to 9,999 addenda records. 

SUBSECTION 14.1.19 " DNE entry " or "DNE" 

means a notice to an RDFI of the death of a Receiver. 
Only an agency of the Federal Government may originate 
a DNE entry. 

SUBSECTION 14.1.20 " Electronic " 

means relating to technology having electrical, digital, 
magnetic, wirele ss, optical, electromagnetic , or similar 
capabilities. 

SUBSECTION 14. 1 .21 " Electronic Record " 

means an agreement, authorization, written statement 
under penalty of perjury, or other record created, 
generated, sent, communicated, received, or stored by 
electronic means. 



SUBSECTION 14.1.23 " ENR entry " or "ENR" 

means a credit or debit enrollment entry initiated by a 
participating DFI to a Federal Government Agency on 
behalf of an account holder at the DFI and who requests 
the initiation of the ENR. An ENR entry may contain up 
to 9,999 addenda records. 

SUBSECTION 14.1.24 " Entry " 

means an order or request complying with the 
requirements of Appendix Two (ACH Record Format 
Specifications) ( 1 ) for the transfer of money to the 
account of a Receiver (a "credit entry"), (2) for the 
withdrawal of money from the transaction account or 
general ledger account of a Receiver (a "debit entry"), (3) 
a zero dollar entry, (4) a DNE entry, or (5) an ENR entry. 
For all entries except RCK entries, each debit entry shall 
be deemed an "item" within the meaning of Revised 
Article 4 of the Uniform Commercial Code (1 990 Official 
Text) and that Article shall apply to such entries except 
where the application is inconsistent with these rules, in 
which case these rules shall control. An RCK entry is an 
item as defined by Revised Article 4 of the Uniform 
Commercial Code only for the limited purposes of 
presentment as set forth in Article 4-1 10(c) and notice of 
dishonor as set forth in Article 4-30 1(a)(2). 

SUBSECTION 14.1.25 " Entry data " 

means, as applicable, prenotifications, returned entries, 
adjustment entries, notifications of change and/or other 
notices or data transmitted through one or more ACH 
Operators pursuant to these rules. 

SUBSECTION 14.1.26 " Existing Relationship " 

The Originator and Receiver have an existing relationship 
when there is a written agreement in place between the 
Originator and the Receiver or when the Receiver has 
purchased goods or services from the Originator within 
the past two years. 

SUBSECTION 14.1.27 "File" 

means a group of entries complying with the requirements 
of Appendix Two (ACH Record Format Specifications), 
associated with a given transmittal register and the control 
totals set forth therein. 

SUBSECTION 14.1.28 " Inbound entry " 



SUBSECTION 14.1.22 " Electronic Signature " 

means an electronic sound, symbol, or process attached to 
or logically associated with an agreement, authorization, 
written statement under penalty of perjury, or other record 
and executed or adopted by a person with the intent to 
sign the record. 



means an entry that originates in another country and is 
transmitted to the United States. An inbound cross-border 
entry includes both inbound CBR entries and inbound 
PBR entries. 

SUBSECTION 14.1.29 " MTE entry " or " MTE " 

means a credit or debit entry initiated at an electronic 
terminal as defined in Regulation E of the Board of 
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Governors of the Federal Reserve System, to effect a 
transfer of funds to or from the consumer's account 
maintained with an RDFI, i.e., an ATM cash deposit or 
withdrawal. 

SUBSECTION 14. 1 .30 " Midnight of a banking day " 

means midnight of the calendar day on which such 
banking day falls. 

SUBSECTION 14.1.31 "National Association" 



means the National Automated Clearing House 
Association. 

SUBSECTION 14.1.32 " Non-Settled entry " 

means an entry for which settlement cannot be completed 
under the rules governing the settlement of that entry. 

SUBSECTION 14. 1 .33 " Organization " 

means a corporation, partnership, association or other 
entity, governmental or private, or a natural person, 
provided that, in the case of a natural person, any account 
of such person to be debited or credited with the amount 
of any entry is maintained primarily for commercial and 
not for personal, family or household purposes. 

SUBSECTION 14. 1 .34 " Originating Automated Clearing 
House Operator " or " Originating ACH Operator " 

means an ACH Operator that receives entries from an 
ODFI with which it has an agreement. In the event entries 
and entry data are transmitted between an ODFI and an 
RDFI through a single ACH Operator, the term shall be 
deemed to refer to that ACH Operator. 

SUBSECTION 14. 1 .35 " Originating Depository Financial 
Institution " or " ODFI " 

A Participating Depository Financial Institution is an 
ODFI with respect to entries (1) it transmits directly or 
indirectly to its ACH Operator for transmittal to anRDFI, 
and (2) on which it is designated as the ODFI in 
accordance with Appendix Two (ACH Record Format 
Specifications). 

SUBSECTION 14.1.36 " Originating Gateway Operator " 
or" OGO " 

An Originating Gateway Operator must be either an ACH 
Operator or a Receiving Depository Financial Institution, 
as defined by these rules. An Originating Gateway 
Operator that also acts as an ACH Operator is deemed to 
have assumed the specific responsibilities and warranties 
of the RDFI with respect to cross-border transactions. By 
transmitting a cross-border payment to a Receiving 
Gateway Operator, an Originating Gateway Operator 
implicitly agrees to comply with the requirements of the 
Cross-Border Payment Operating Rules. 



SUBSECTION 14. 1 .37 "Originator" 

4 means ( 1 ) a person that has authorized an ODFI to send or 
transmit, for the account of that person, (i) a credit entry 
to the account of a Receiver with an RDFI, or, if the 
Receiver is also the RDFI, to such Receiver, in order to 
effect a payment from that person to the Receiver, or (ii) 
a debit entry to the Receiver's transaction account or 
general ledger account with an RDFI, or, if the Receiver 
is also the RDFI, to such Receiver, in order to effect a 
payment from the Receiver to that person; or (2) a person 
that has authorized a Third-Party Sender to send or 
transmit to an ODFI for the account of that, or another, 
Third-Party Sender, (i) a credit entry to the account of a 
Receiver with an RDFI, or, if the Receiver is also the 
RDFI, to such Receiver, in order to effect a payment from 
that person to the Receiver, or (ii) a debit entry to the 
Receiver's transaction account or general ledger account 
with an RDFI, or, if the Receiver is also the RDFI, to such 
Receiver, in order to effect a payment from the Receiver 
to that person. Where the context so requires, as in the 
case of MTE entries, that term also refers to the ODFI. 

SUBSECTION 14. 1.38 " Outbound entry " 

means an entry that originates in the United States and is 
transmitted to another country. An outbound cross-border 
entry includes both outbound CBR entries and outbound 
PBRentries. 

SUBSECTION 14.1 .39 " Participating Depository 
Financial Institution " or " Participating DFI " 

means a financial institution that ( 1 ) is authorized by law 
to accept deposits, (2) has been assigned a routing number 
by Thomson Financial Publishing, and (3) has agreed to 
be bound by these rules as in effect from time to time. A 
Participating DFI of an Association is a Participating DFI 
which is a member of such Association or authorized by 
such Association to transmit entries and receive entries 
from an ACH Operator. Only Participating DFIs may act 
as ODFIs or RDFIs. 

SUBSECTION 14. 1 .40 " PBR entry " 

means a credit or debit entry initiated to effect a payment 
exchanged between payment system participants of 
different countries, via an Originating Gateway Operator 
and a Receiving Gateway Operator, to or from a 
Consumer Account of the Receiver. 

SUBSECTION 14.1.41 "Person" 

means a natural person or an organization. 

SUBSECTION 14.1.42 " POP entry " 

means a Single Entry debit initiated by an Originator 
pursuant to a source document as set forth in subsection 
3.8.1 (Source Documents), provided to the Originator by 
the Receiver at the point-of-purchase to effect a transfer 




§ Approved December 2, 2003; Effective December 10, 2004 



OR 35 



ARTICLE FOURTEEN 



2005 OPERA TING RULES 



of funds from a Consumer Account of the Receiver. This 
type of entry may only be used for non-recurring, in- 
person (i.e., at the point-of-purchase) entries for which 
there is no standing authorization with the Originator for 
the origination of ACH entries to the Receiver's account. 

SUBSECTION 14.1.43 " POS entry " 




means a debit entry initiated at an electronic terminal as 
defined in Regulation E of the Board of Governors of the 
Federal Reserve System to effect a transfer of funds from 
a Consumer Account of the Receiver to pay an obligation 
incurred in a point-of-sale transaction, or to effect a 
point-of-sale terminal cash withdrawal, and reversing, 
adjusting, and other credit entries relating to such debit 
entries, transfer of funds or obligations. 

SUBSECTION 14.1.44 " PPD entry " 

means a credit or debit entry (other than an MTE or POS 
entry) initiated by an organization pursuant to a standing 
or a single entry authorization from a Receiver to effect a 
transfer of funds to or from a Consumer Account of the 
Receiver. "PPD+" is a PPD entry with one addenda 
record. 

SUBSECTION 14.1.45 " RCK entry " 

means a Single Entry debit constituting a presentment 
notice of an item eligible under Section 2.8 (Re-presented 
Check Entries). An RCK entry is an item as defined by 
Revised Article 4 of the Uniform Commercial Code ( 1 990 
Official Text) only for the limited purposes of 
presentment as set forth in Article 4-1 10(c) and notice of 
dishonor as set forth in Article 4-301(a)(2). 

SUBSECTION 14.1.46 "Record" 

means information that is inscribed on a tangible medium 
or that is stored in an electronic or other medium and is 
retrievable in perceivable form. 

SUBSECTION 14.1.47 "Receiver" 

means a person that has authorized an Originator to 
initiate ( 1 ) a credit entry to the Receiver's account with an 
RDFI, or, if the Receiver is also the RDFI, to such 
Receiver, or (2) a debit entry to the Receiver's transaction 
account or general ledger account with an RDFI, or, if the 
Receiver is also the RDFI, to such Receiver. With respect 
to debit entries, the term "Receiver" shall be deemed to 
mean all persons whose signatures are required to 
withdraw funds from an account for purposes of the 
warranty provisions of subsection 2.2. 1 (Warranties). 

SI IBSECTIQN 14. 1 .48 " Receiving Automated Clearing 
House Operator " or " Receiving ACH Operator " 

means an ACH Operator that distributes entries to an 
RDFI with which it has an agreement. In the event entries 
or entry data are transmitted between an ODFI and an 



RDFI through a single ACH Operator, the term shall be 
deemed to refer to that ACH Operator. 

SUBSECTION 14,1.49 " Receiving Depository Financial 
Institution " or " RDFI " 

A Participating Depository Financial Institution is an 
RDFI with respect to entries (1) it receives from its ACH 
Operator for debit or credit to the accounts of Receivers, 
and (2) 'on which it is designated as the RDFI in 
accordance with Appendix Two (ACH Record Format 
Specifications). 



SUBSECTION 14.1.50 " Receiving Gateway Operator " or 
"RGO" 



A Receiving Gateway Operator must be either an ACH 
Operator or an Originating Depository Financial 
Institution, as defined by these rules. A Receiving 
Gateway Operator that also acts as an ACH Operator is 
deemed to have assumed the specific responsibilities and 
warranties of the ODFI with respect to cross-border 
transactions. By receiving a cross-border payment from 
an Originating Gateway Operator, a Receiving Gateway 
Operator implicitly agrees to comply with the 
requirements of the Cross-Border Payment Operating 
Rules. 

SUBSECTION 14.1.51 " Receiving Point " 



means a person that receives entries from an ACH 
Operator on behalf of an RDFI. A Receiving Point may 
be an RDFI acting on its own behalf, a Participating DFI, 
a commercial data processing service organization; or a 
person operating a data transmission facility, acting on 
behalf of one or more RDFIs. 

SUBSECTION 14.1.52 "Send" 

means to deposit in the mail or to communicate by any 
other usual means with postage or cost of transportation 
provided for and properly addressed, or by facsimile. 

SUBSECTION 14.1.53 " Sending Point " 

means a person that transmits entries to an ACH Operator 
on behalf of an ODFI. A Sending Point may be an ODFI 
acting on its own behalf, or a Participating DFI, a 
commercial data processing service organization or a 
person operating a data transmission facility, acting on 
behalf of one or more ODFIs. 

SUBSECTION 14.1,54 " Settlement Date " 

means the date an exchange of funds with respect to an 
entry is reflected on the books of the Federal Reserve 
Bank(s). 
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SUBSECTION 14. 1 .55 " SHR entry " 

means a debit entry initiated at an electronic terminal as 
defined in Regulation E of the Board of Governors of the 
Federal Reserve System to effect a transfer of funds from 
a Consumer Account of the Receiver to pay an obligation 
incurred in a point-of-sale transaction, or to effect a 
point-of-sale terminal cash withdrawal, and reversing, 
adjusting, and other credit entries relating to such debit 
entries, transfer of funds or obligations. SHR entries are 
initiated in a shared network where the ODFI and RDFI 
have an agreement in addition to these rules to process 
such entries. 



SUBSECTION 14.1.56 " Single Entry " 

means a one-time transfer of funds initiated by an 
Originator in accordance with the Receiver's 
authorization for a single ACH credit or debit to the 
Receiver's Consumer Account. 

SUBSECTION 14.1.57 " TEL entry " 

means a Single-Entry debit initiated by an Originator 
pursuant to an oral authorization obtained over the 
telephone to effect a transfer of funds from a Consumer 
Account of the Receiver. This type of entry may only be 
used for a Single Entry for which there is no standing 
authorization for the origination of ACH entries to the 
Receiver's account. A TEL entry may only be used when 
there is an Existing Relationship between the Originator 
and the Receiver, or, when there is not an Existing 
Relationship between the Originator and the Receiver, 
when the Receiver initiates the telephone call. 

$ SUBSECTION 14.1.58 " Third-Party Sender " 

means a person that is not an Originator that has 
authorized an ODFI or another Third-Party Sender to 
transmit, for the account of the Third-Party Sender or 
another Third-Party Sender, (i) a credit entry to the 
account of a Receiver with an RDFI, or, if the Receiver is 
also the RDFI, to such Receiver, in order to effect a 
payment from the Originator to the Receiver, or (ii) a 
debit entry to the Receiver's transaction account or 
general ledger account with an RDFI, or, if the Receiver 
is also the RDFI, to such Receiver, in order to effect a 
payment from the Receiver to the Originator. 

SUBSECTION 14. 1 .59 " Third-Party Service Provider " 



means an entity other than an Originator, ODFI, or RDFI 
that performs any functions on behalf of the Originator, 
the ODFI, or the RDFI related to ACH processing of 
entries, including but not limited to, the creation of ACH 
files or acting as a sending or receiving point on behalf of 
a Participating DFI. 



SUBSECTION 14.1.61 " TRC entry " 

means a debit entry initiated pursuant to a check 
truncation program. 

SUBSECTION 14.1.62 "Truncation" 



means a process whereby checks are presented by 
transmission of information describing the check rather 
than by the delivery of the check itself. 

SUBSECTION 14.1.63 " TRX entry " 

means an entry initiated pursuant to a check truncation 
program. Multiple checks are placed in the Payment 
Related Information section of the Addenda Record in 
accordance with National Association for Check 
Safekeeping syntax. A TRX entry can contain up to 9,999 
addenda records. 

SUBSECTION 14. 1 .64 " Unsecured Electronic Network " 

means a network, public or private, that is not located 
entirely within a single, contiguous, physical facility and 
any part of which that has not implemented security 
technologies that provide a level of security that, at a 
minimum, is equivalent to 128-bit RC4 encryption 
technology. 

SUBSECTION 14.1.65 " WEB entry " or " WEB " 




means a debit entry initiated by an Originator pursuant to 
an authorization that is obtained from the Receiver via the 
Internet to effect a transfer of funds from a Consumer 
Account of the Receiver. 



SUBSECTION 14.1.66 " XCK entry " 

means a debit entry initiated in the event an item eligible 
for section 2.7 (Destroyed Check Entries) is contained 
within a cash letter that is lost, destroyed, or otherwise 
unavailable to and cannot be obtained by an ODFI. 



SUBSECTION 14.1.67 " Zero Dollar Entry " 



SUBSECTION 14.1.60 " Transmit " 

means to deliver by electronic means of communication. 



means an entry which carries a zero amount but does 
include payment related remittance data. Zero dollar 
entries are limited to CTX and CCD entries that carry 
remittance data related to the payment. For example, pre- 
advice entries that carry remittance data that indicates a 
credit position of the Originator to the Receiver, or entries 
relating to a period of time during which no funds are 
owed by the Originator to the Receiver. 

SECTION 14.2 Construction Rules 

Unless the context otherwise requires, words in a singular 
number include the plural, and in the plural include the 
singular. The term "section" refers to a subdivision of an 
Article containing a two-digit number (e.g., "2.1"); the 



& Approved December 2, 2003; Effective December 10, 2004 
Approved December 2, 2003; Effective September 10, 2004 



OR37 



APPENDIXONE 



2005 OPERATING RULES 



term "subsection" refers to a subdivision of a section 
containing a three or four-digit number (e.g., "2.1.1"). 



THE APPENDICES 

SPECIFICATIONS 



TECHNICAL 




APPENDIX ONE — ACH FILE: 
EXCHANGE SPECIFICATIONS 

The following information outlines the requirements for 
processing electronic transmissions, addresses the 
sequence of records in an ACH file, and gives a 
descriptive overview of the various logical records 
contained in a file. 

SECTION 1.1 Electronic Transmission 
Requirements 

To ensure compatibility in electronic file transmission, 
necessary operating details (testing and implementation 
plans) need to be addressed between a Participating DFI 
and its Automated Clearing House Operator. 

SECTION 1.2 ACH Tape Specifications (Contingency 
use only, subject to approval by an ACH Operator) 

ACH Standard Labels 

The use of labels provides greater security and control 
over processing and provides a direct input to inventory 
and control procedures. Failure of ACH files to conform 
to these specifications will be cause for file rejection by 
the processor. There are three types of labels which must 
appear on a magnetic tape. 

These include: 

VOL! -Beginning of Volume 
HDR1 --Beginning of File 
EOFl-EndofFile 

The VOL 1 label appears at the beginning and identifies 
the volume and its owner. The HDR1 label identifies the 
data file and provides security and control information 
relative to that file. The EOF1 also identifies the data file 
and tape volume and provides the checking mechanism 
for processing verification (i.e., block counts). These 
labels contain sufficient information and provide the 
physical characteristics to accommodate processing and 
control requirements. 

Optionally, the HDR2 and EOF2 labels may be resident 
within the tape label structure. These labels normally 
contain additional information about the associated data 
file and can be ignored at the option of the processor. 



The code structure for all labels is the same as specified 
for the data file; a nine-track tape must be recorded in 

. ebcdic. v : :;v. v / ;: 'v ^ 

ACH Label Structure 

See applicable Automated Clearing House Operator for 
data set label configuration. 

SECTION 1.3 Data Specifications 

All alphameric and alphabetic fields must be left justified 
and space filled. All numeric fields must be right 
justified, unsigned, and zero filled. Characters used in 
ACH records are restricted to 0-9, A-Z, space, and those 
special characters which have an EBCDIC value greater 
than hexadecimal "3F" or an ASCII value greater than 
hexadecimal " IF". Occurrences of values EBCDIC "00" - 
"3F" and ASCII "00" '.- "IF" are not valid. 

SECTION 1.4 Sequence of Records in ACH Files 

Each file begins with a File Header Record. After the File 
Header may be any number of batches. Each batch is 
identified by a Batch Header Record and contains one or 
more Entry Detail Records. The number of addenda 
records that accompany each entry is dependent upon the 
Standard Entry Class Code. At the end of each batch is a 
Batch Control Record. Each file is ended with a File 
Control Record. 

The records in ACH files must be in the following 
sequence: 

ACH Header Label Record(s) 
File Header Record 
BatchM 

Company/Batch Header Record 

Entry Detail Records or Corporate 
Entry Detail Records (with/without 
optional Addenda Records) 
Company/Batch Control Record 
Batch#2 

Company/Batch Header Record 

Entry Detail Records or Corporate 
Entry Detail Records (with/without 
optional Addenda Records) 
Company/Batch Control Record 
Batch #« 

Company/Batch Header Record 

Entry Detail Records or Corporate 
Entry Detail Records (with/without 
optional Addenda Records) 
Company/Batch Control Record 
File Control Record 
ACH Trailer Label Records 

Any other sequence will cause the file to be rejected (see 
diagrams on the following pages). 
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SECTION 1.5 Fifie Structure 

File Header Record 

The File Header Record designates physical file 
characteristics and identifies the immediate origin 
(Sending Point or ACH Operator) and destination 
(Receiving Point or ACH Operator) of the entries 
contained within the file or within the transmitted batched 
data. In addition, this record includes date, time, and file 
identification fields which can be used to identify the file 
uniquely. 

Company/Batch Header Record 

The Company/Batch Header Record identifies the 
Originator and briefly describes the purpose of the entry. 
For example, "GAS BILL" or "REG SALARY" indicates 
the reason for the transaction originated by the Originator. 
The Company/Batch Header Record contains the Routing 
Number of the ODFI for settlement, routing of returns, 
and other control purposes. In addition, the 
Company/Batch Header Record can indicate the intended 
effective entry date of all transactions within the batch. 
The information contained in the Company/Batch Header 
Record applies uniformly to all subsequent Entry Detail 
Records in the batch. 

Entry Detail Record, Corporate Entry Detail Record 

Entry Detail Records contain that information sufficient to 
relate the entry to the Receiver, i.e., individual DFI 
account number, identification number, name, and the 
debit or credit amount as indicated by the Transaction 
Code. 

The information in the Company/Batch Header Record 
must be incorporated with the Entry Detail Records to 
describe fully that entry and all participants in the 
transaction. The information in the Company/Batch 
Header Record identifies the Originator; the Trace 
Number identifies the ODFI; DFI account information 
identifies both the RDFI and the specific account. In 
addition to the basic entry format, Transaction Codes for 
Entry Detail Records have been defined to accommodate 
prenotification records, zero dollar entries, and return 
entries. 

Prenotifications are identical to the basic entry format but 
contain appropriate Transaction Codes and zeros in the 
Amount field, Prenotifications can be batched with other 
dollar entries or batched separately. 

Zero dollar entries are identical to the basic entry format 
but contain appropriate Transaction Codes and zeros in 
the Amount field. Zero dollar entries can be batched with 
other CCD or CTX dollar entries or batched separately. 
A zero dollar entry must be accompanied by at least one 
Addenda Record. 



Return entries are distinguished by special Transaction 
Codes and must be batched separately from other dollar 
entries. 

Addenda Record 

Addenda records will be used by the Originator to supply 
additional information about Entry Detail Records that 
will be passed from the ODFI through the ACH Operator 
to the RDFI. Addenda records associated with the 
original Entry Detail Record or Corporate Entry Detail 
Record will not be included with any Entry Detail Record 
being returned. Only NACHA sanctioned formats will be 
permitted, as specified by the Addenda Type Code. 
Addenda record information may only be used for the 
purpose of transmitting payment related information. Any 
other use is prohibited. Each application and its 
corresponding number of addenda records is listed below: 




MAXIMUM NUMBER 
APPLICATION CONTENTS ADDENDA RECORDS 


(OPT/MAN) 


ACK 


ANSI ASC X12REF 
(Reference) data segment 


1 


optional 


ATX 


ANSI ASC X12REF 
(Reference) data segment 


1 


optional 


CBR 


See Appendix 2.1 


1 


mandatory 


CCD, PPD 


Payment related 
ANSIASCX12 
data segments, 
NACHA endorsed 
banking convention 


1 


optional 


cm 


Payment Related ANSI 
ASC X12 data segments 


1 


optional 


COR 

Refused COR 


See Appendix Six 
(Notification of Change) 


1 


mandatory 


CTX 


ANSIASCX12.5orX12.6 
syntax, an ASC X12 transaction 
set containing a BPR or BPS 
data segment, or payment related 
UN/EDIFACT syntax 


9,999 


optional 


DNE 


NACHA endorsed 
banking convention 


1 


mandatory 


ENR 


NACHA endorsed 
banking convention 


9,999 


mandatory 


PBR 


See Appendix 2.1 


1 


mandatory 


POS,SHR, 

MTE 


See Appendix 2.1 


1 


mandatory 
(unless prenote) 


Returns, 

Dishonored 

Returns, 

Contested 

Dishonored 

Returns 


See Appendix Five 
(Return Entries) 


1 


mandatory 


TRX 


National Association for 
Check Safekeeping syntax 


9,999 


mandatory 


WEB 


Payment related 
ANSI ASC X12 
data segments, 
NACHA endorsed 
banking convention 


1 


optional 
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Company/Batch Control Record 




The Company/Batch Control Record contains the counts, 
hash totals, and total dollar controls for the preceding 
detail entries within the indicated batch. 

All Entry Detail Records are hashed. Both Entry Detail 
Records and Addenda Records are included in the 
entry/addenda counts; Batch Header and Batch Control 
Records are not included. 

File Control Record 

The File Control Record contains dollar, entry, and hash 
total accumulations from the Company/Batch Control 
Records in the file/This record also contains counts of 
the number of blocks and the number of batches within 
the file (or batched data transmitted to a single 
destination). 
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APPENDIX ONE 



Diagram of Sequence of Records for -ACK,- ARC,- ATX, CBR 5 CCD, COR, CIE, 

DNE, MTE, PBR, POP, POS, PPD, RCK, SHR, TEL, and WEB Entries 



ACH Header Label Record(s) 



File Header Record 



Company/Batch 
Header Record 



First Entry 
Detail Record 



Second Entry 
Detail Record 



Last Entry 
Detail Record 



Company/Batch 
Control Record 



Company/Batch 
Header Record 



First Entry 
Detail Record 



Last Entry 
Detail Record 



Company/Batch 
Control Record 



File Control Record 



9999.. .99999 



ACH Trailer Label Record(s) 



'Contingency use only 



>> 



JJ 



^\ 



>> 



D 



First physical record(s) on file 
(Magnetic Tape Files only)' 



One per file - first logical record on file 
One per batch 



Each entry detail may have an optional 
Addenda record 




Batch 1 



One per batch 

Batches 2 through n-1 



Batch n 



One per file - East logical record 

File used to complete last physical block 



Last physical record(s) on file 
(Magnetic Tape Files only)* 



OR 4 1 





APPENDIX ONE 




















2005 OPERA TING R ULES 


Diagram of Sequence of Records for CTX, ENRj and TRX Entries 




ACH Header Label Record(s)* 










File Header Record 










CTX or ENR Company/Batch 
Header Record 












(Corporate) Entry Detail Record 

CompanyA 










Addenda Record 

#1 




'.'■■'■ 


Addenda Record 






Addenda Record 








Addenda Record 

#n 






(Corporate) Entry Detail Record 
Company B 










Addenda Record 






Addenda Record 

#2 




■ . ■ ■ ■ . ■ . . ' ' 


Company/Batch Control Record 










Batches 2 through n 








File Control Record 

QQQO QOQOQ 
9399... .99993 








ACH Trailer Label Record* 










'Contingency Use Only 
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APPENDIX TWO 



SECTION 1.6 Trace Number Sequence in ACH Files 

Sending Points must always prepare files so that 
individual Entry Detail Records within individual batches 
are in ascending Trace Number order (although Trace 
Numbers need not necessarily be consecutive). The Trace 
Number in an Addenda Record is the same as that of the 
Entry Detail Record with which the Addenda Record is 
associated. 

For corporate entries, the CTX Entry Detail Sequence 
Number in an Addenda Record is the same as that of the 
Corporate Entry Detail Record with which the Addenda 
Record is associated. 

For check truncation entries, the TRX Entry Detail 
Sequence Number in an Addenda Record is the same as 
that in the Trace Number of the Entry Detail Record with 
which the Addenda Record is associated. 

Addenda Records must be in consecutive ascending order 
by the Addenda Sequence Number. 



APPENDIX TWO - ACH RECORD 
FORMAT SPECIFICATIONS 



The ACH record format specifications are designed to 
assist ACH participants in properly formatting and 
retrieving transaction information. This section details the 
contents of the various record formats and defines the 
code values and data elements. The inclusion 
requirements, contents, and lengths of data elements are 
illustrated in the record formats, which are arranged 
according to their sequence in the file. The glossary 
defines and explains the application of each field. 

SECTION 2.1 Record Formats 



and Addenda Records according to Standard Entry Class 
Code. 



On the following pages are the ACH record formats. The 
first record formats (2.1.1) are the File Header and File 
Control Records. These two records act as the outermost 
envelope of an ACH transaction and convey information 
related to the destination and origin of the transaction as 
well as the total amount of debits and credits within the 
file. The format of these records is consistent for all 
entries, regardless of the Standard Entry Class Code. 

The second set of record formats (2.1.2) contains the 
Company/Batch Header and Company/Batch Control 
Records. The Batch Records act as an inner envelope 
combining similar entries and providing information about 
the Originator. Like the File Records, the format of these 
records is consistent for all entries, regardless of the 
Standard Entry Class Code (with the exception of AD V, 
CBR, and PBR entries). The remaining Sequence of 
Records (2. 1 .3 - 2. 1 .23) contain the Entry Detail Records 




OR 43 



APPENDIX TWO 



2005 OPERATING RULES 




a 



E 

o 

to 

u 

O 
« 



u 



o 

H 

u 

tzi 

n 
p 



Q 

0: 
o 
a 

LU 

Q£ 

LU 
Q 
< 
LU 
X 

UJ 



(0 

LU 

I- 

UJ 





LU 










CO 


O 

z LU 

ffi8 

LU 
DC 


O 


g 

E 

(0 

.c 

Q. 
< 


ao 


■? 

00 




LU 




o 








Sziu 




<D 






CM 


Q O 2 


O 


E 


CO 


OO 


■ *~ 


ma: < 


TO 


CM 


-?■ 




|O z 










s 




.< 




















. . z 












LUg 




<-> 








q 5 5 
LU — < 




CD 






£ 


o 


E 
TO 


CO 
CM 


CD 




llr- 




CL 




•«*■ 






< 








~ a 












H 












< LU 








o 


O 


2 a 
a: O 
O o 
u- 


2 


■ ' * 




o 

**• 
















rs O 








CD 


9> 


O o 
CQ 


2 


o 


<N 


CO 

c6 

CO 




Q 










CO 


£ LU 

uj« 

a: 


2 


p 


CO 


CO 

uS 

CO 




ec 




NO 








a lu 


2 


£?J<? 




<* 

CO 




-J Q 


CL CO 2 O 




■s 




ll O 




Z> < O ■ 






2 




o z 








z 












o 












h_ 










to 


LU 

. -J 
LL 


O 


2 

X 

■ X 


rr 


CO 

cp 

6 

CO 




Z 












o 












F 




■ . . a 








< LU 




a 




en 


m 


LU t- 
CC < 


2 


2 


(0 


CM 




o o 

LU 




£ 




CM 




_i 












u. 












LU 




O 








S* 




| 




CO 


rr 


lu q: 

1° 


2 


XJ 


o 


CM 

■4 




■■pi 




o 






CO 


a z 

ui.S 

2 LU 

a 


2 


XI 


o 


CO 
O 




£u, 




■■■■ o 




CO 




tt a 




QJ 




o 


CM 


oo 


a: 


E 


CM 


CM 




5£0 




z 




O 




D- 












D 












a: lu tu 










T ". 


o >- o 

LU t- O 

a: 


2 


r~ 


■ " r " 


O 
O 


















•- 












c 










K 


Q) 










e 


C £ 








O 

LU 


•— tu s 
^ -J ^ 


moo 


c 
o 


■c. 

c 


c; 
.O 

Si 
o 


LL. 


QUJ2 


ill -E ft: 


O 


~J 


a. 



Q 

or 

O 
O 
LU 

or 

_i 
o 

01 

I- 
z 

o 
o 

LU 

_l 

LL. 

CO 
LU 

0T 

I- 

z 

LU 





a 










. «0 


i 

LU 


'■'■'■ 5 
z 


■ c 

CO 


CO 


CO 




CO 




CQ 




m 




LU 












OS 












b'«3 




^t*. 






r- 


TOTAL CRED 
ENTRY DOLL/ 
AMOUNT IN Fl 


2 


8 


CM 


U5 
IT) 






» 








UL LU 












BIT 
LA 
FIL 




to 








lu =; z 

n O ~ 




CO 




CO 


« 


TOTAL 
ENTRY D 
AMOUNT 


. 2 


to 
to 


CM 


CM 
CO 




' . .' X 




o 






in 


>- 


5 


0J 

F 


o 


cp 




£ 




■ D 








1- 




. z 








Z 












LU 










-» 


ENTRY/ 

ADDENDA 

COUNT 


2 


M 

■ 3 


CO 


CM 

4- 




o Z 




O 




CO 


CO 


= 

_i o 


.2 


E 

3 


(D 


o 




CO o 




z 




CM 


mo 


.'■.' 2 


u 

E 

■ 3 

2 


to 


9 

CM 
O 




Q 












DC LU LU 








^- 




RECO 
TYP 
COD 


■. -s 


O) 




9 
o 


















■ c 










l- 


a> 










X 


c.-E 


o) 






D 

_t 

LU 
LL 


DATA 

ELEME 

NAME 


Field 

Inclusio 

Require 


c ■ 

0) 

3 


C 


V) 

:&■'■ 



OR 44 



2005 OPERA TING RULES 



APPENDIX TWO 







a: 




m 




a. 




«j 


0> 




a: 
do 






o 


fl 


£ 


i- 


w 


C 


Q. 


s 


PQ 


LU 


<d 


PQ 


o 


1- 




X 


5 


OQ 


LU 


eg 


U 


o 


s 

o 
© 


'a. 


o 


< 

o 


o 

LU 

a: 


0> 


o 

o 


LU 

a 




O 

u 


< 

LU 






X 




o 


I 
O 


<1 


J5 ■ ■ 
o 


5 


<S 73 


03 


• >* 


>: 


^ § 


z 


S 1" 


< 


© M 


a. 


H .2 


o 
o 


UBS 

(Not< 


LU 


c» 




Q£ 



UJ 



<o 


Pn 


. 2 




0) 

E 
z 


h- 


00 
00 




z 












O 












z c 




< 








H < 










CM 

r- 


<LT9 

f OIL 

i i 
S . jjj- 


2 


i 


00 


CO 

s 




C£ 










r- 


15S 


2 


CD 

E 
ro 


^ 


CD 








a. 
< 




K 




o 












1- 


,_ 










z 


>*5 










UJ z 


-Q CO 









O 




•0 0) 

1" 


a) 

E 


CO 


00 

(O 




LU 


« x 

£. 


z 




r»- 




« 


< 










LU 










at 




QC 


Q 
Q 

2 


(O 


10 
6 




LL m a 
U. "* 
LU 




£ 




r- 




>- 5: 











00 


lis 

a 


O 


E 

a. 
< 


CD 






. z 












>. o 




u 






>* 




S 


E 
ro 

a 
< 





CO 
CO 




_ UJ 












9 a 











to 


g>.o 

§ z 8 
w 6 


2 


0) 

E 

CQ 

H 

a. 
< 


<*) 


CO 

If) 
10 




z 












^° 












>p 











in 


5 < 

H 

9 


5 


a> 

E 
ro 

■ x: 
a. 
< 









>- 












a: 












>■ < 













z z 




■c 






^ , 


£lu< 

o a Q 





1 

ro 




CM 




7 






Q. 








o o 




< 








to 












a 












'. >- ■' 











n 


o z 
o 


2 


a) 

E 
ro 

a 
< 


CD 




CNI 

If) 





LU 

O « LU 









Tf 


CM 


>3s 


2 


E 


CO 




CNI 




LU o^ 




z 









a 












0C LU LU 










1 ~ 


09-9 
>- 

UJ f- 
a: 


2 


LO 


, ~ 






















H- 












c 










K 


03 










e 


c E 


J2 






a 

-i - 


K- LU S 


g 

pi* 


i. 


CD 

-J 


.^ 


LU 

Lt 


<* .4 ^ 


itso: 


8 


£ 





- 


Pa 

2 = 


5 




c 

CD 

£ 

■ D 

z 


r- 


■■'! 

CO 




















U- Z 














OO 














OP 




< 










z < 




5 




r^ 




O 


t y 


5 


5 




°? 






Sp 


F 




;S 






z . 




L 










S uj 














¥ Q 














O- 














a 














LU 














> 




^ 




O) 




o» 


LU 

to 

LU 

a: 


< 

■ ■ .■ z 


ro 
CQ 


CD 


1^. 
•4- 
1^ 


Q 














QC 




■ z ' ■' 










O 




ESSAGE 

ENTICATIO 

CODE 










O 

LU 

DC 


€0 







CD 

a 





CO 

■■5 






S £ 




< 






J 




■■*=;■■ 










O 




< 










K 




z 










h- 




°2 




u 






Z 
O 
O 


N. 


a: 


CU 

E 

ra 

< 





-5 


X 




9 















an z 










< 






to 




Tf 


tn 


to 


TOTAL C 

ENTRY D( 

AMOL 


2 


66 


CN 


T 


> 

z 










CO 


< 


























a, 

S 




L DEBIT 
DOLLAR 
OUNT 










O 


10 


2 


CM 


CO 


O 




M 1 






CM 


w 




•-iS 




m 






LU 








































a 




15 '± 






' 'C 






1- 

z 


•* 


zS 

UJ x 


: . 2 


CD 

E 

. D 

z 





CM 


LU 














-J 














_J 




< 










< 




S z z 






•c 




O 




« 


H LU D 


2 


E 


CD 








z Q O 












LU O O 
< 




z 










LU 

o«ui 




,y 








tM 


> S? Q 

LUo O 
(0 


:■' 2 


CD 

E 

■ . 3 

. z 


CO 


O 
CM 
O 






Q 














0£ HI LU 












^. 


09-9 
O >* O 
LU f- O 


. s 


9° 




9 
O 






















H- 














■ c 












K 


CO 












X 


c e 


w 








Q 

_l 

LU 
LL 


Q Uj ^ 




s 


CD 

-J 


1 




OR 45 



APPENDIX TWO 



2005 OPERATING RULES 












u 




+-» 




a 




W 








& 




PQ 




PM 




TS 




^ 




08 




tf 




PQ 




u 


Q 


t-l 


& 


T5 


O 


e 


O 
m 


w 




o 


K 


k* 


LLJ 


U 


Q 


u 


< 


a 




+^ 


X 


C3 




£ 


I 


u 


o 


o 


1- 


ta 


< 


•o 


QQ 


^ 




o 


' :■>- 




Z 


& 


< 


1m 


a. 


0> 


S 


A 


o 




o 


^ 

o 


£D 


^ 

A 




go 


■o 


> 


c 


s 


re 


o 


£ 


g 


m 


o 


o 


U 





en 

* 

Z 

o 

H 
U 

W 

« 



I 



5CH 

? Q U. 

<2 fc 
a: s 



^11 

E°3 



o<£3 

W Z q; o 
- 1- nc o 



O < w a 
« z o; o 






2fe 

I- tt u, 



■ sis 

jy -p a 

S§ff 
"■as 



o a. 9 






Eg. 

S5 



o gj 

.0) O Q> 

£ -£ tt: 



o/?^ 



2005 OPERA TING RULES 



APPENDIX TWO 



a 

> 

U 



■a 

© 

to 

o 
to 

s 
u 

< 

o. 

H 
U 

W 

CZ) 

M 

P 
t/3 



Q 
DC 
O 
O 
UJ 
OC 

UJ 
Q 
< 
UJ 

X 
UJ 



> 

Q 
< 

















UJ 












u 












Z . UJ 




OJ 






CO 


8jO 

UJ 

oc 


o 


e 

CD 

■ SZ 

< 


00 


CD 
CO 




UJ 












<C z uj 




CD 




CO 


CM 


qOS 


5 


£ 


co 


00 




so z 


CO 

SZ 


CN 


-3" 
(O 




1 




< 








', z' 












EDIATE 
INATIO 
AME 




O 

■c 
Q) 




CO 




2 


£ 

CO 


CO 

CM 


CO 




iifi z 




a. 




-* 






. < 








~ Q 












■ 1- 












< UJ 








o 


O 


S Q 

oc o 
o o 

u_ 


s 


* 




o 




?* 










ov 


2fc> 

O o 

o< 


. 5 


b 


CN 


CO 
CO 

oo 

CO 


CO 


* UJ 

8* 


: ■ 2 


p 


<"> 


CO 
CO 




oc 




NO 








Q Ul 




W* 




■<r 




*£ 


2 


■ r- 


CO 




_j Q 




£L CO S O 




-** 




c o 




D < => 








s 




o z 








■ Z . 












o 












1- 










to 


OC i 


O 


5 

X 


f 


CO 
CO 

o 




o h 




X 




CO 




UJ 












■ -i ■ 
























u. 












z 












o 












:p . 




o 






in 


^ 


.2 


Q 

2 

2 


CO 


CN 




O Q 

UJ 




£ 




CN 




■ ■ _i 












LL 












UJ 




o 








Ss 




1 




CO 


^f 


Ul (t 

i° 


2 


jo 


o 


CN 

4 


rt 


jU O 

S uj 
Q 


2 




o 


CO 

I 




■ia 




■ 'C 




CO 




ds a 




<u 




o 




o o 


oc 


£ 


CN 


CN 




2<J 




■ ■ Z 




O 




a. 












Q 












a uj uj 










> . 


O Q- Q 
O >- O 
Ul f- o 


■'.■ . 2 


''...-.■ r- 


'■"- 


o 










o 




K 


























^_ 












■ c 










■*■■ 


■ . ■ c E 


42 






a 

■ _i 

UJ 

u. 


t •« 3 

§Gj§ 


Inclusio 
Require 


: . § :'■. 


.s 

-J 


1 



O 
OC 
O 
O 
UJ 

oc 

_i 
o 
oc 

I- 

z 
o 
o 

UJ 



> 

< 



oo 


a 

UJ 
UJ 

« 

UJ 
DC 




c 

CO 
CD 


CO 
CN 


? 

CN 
1^- 


r- 


TOTAL CREDIT 
ENTRY DOLLAR 
AMOUNT IN FILE 


2 


■w- 

Vi 
CO 

«> 

60 
CO 
CO 
CO 

CO 
CO 

to 

SI 

to 
to 

CO 

to 
to 


O 
CN 


CN 

m 


«o 


TOTAL DEBIT 
ENTRY DOLLAR 
AMOUNT IN FILE 


2 


■*». 

CO 

to 

€0 
GO 

to 
to 
to 
to 
to 
to 
to 
to 
to 
to 
to 

.8 


o 

CN 


in 

CN 

co 


to 


. X 

. x 

>- 
OC 

■ . ■ .' 1- 
z 

UJ 


2 


CJ 

■c 
<u 
£ 
z 


O 


CO 
CN 
CN 


■ ■* ■ 


ENTRY/ 

ADDENDA 

COUNT 


s 


1 


CO 


CN 

4- 


w 


rlo 

CO u 


2 


CJ 

■g 

E 

■ ■ 3 

z 


to 


CO 

A 

o 


CN 


PS 

< o 

03 O 


2 


c5 

. £ 

■ D 

z 


CO 


o 

CN 

o 


- 


RECORD 
TYPE 
CODE 


■' '5 


en 


■.-. 


o 
o 














Q 
-J 
UJ 

U. 


< 3 ^ 


Field 

Inclusion 

Requirement 


42 

■ c ■ 

c 

8 


-I 


J 




OR 47 



APPENDIX TWO 



2005 OPERATING RULES 



■ 



T3 

.9 

a 
o 



a 



5 

I* 
o 
o 

2 



& 
a 



o 

H 
W 

« 

P 



Q 

or 

O 
O 

DC 
_l 
O 
DC 
I- 

O 
O 

U 
00 

z 
< 

o 
o 

> 

Q 
< 



o» 




: 2 


u 

E 
z 


1^ 


en 

CO 
CO 


.». 


£ Z 
Q O 
OF 
z < 

< u. 
zp 

§3 

g9 


s 


! 


00 


h- 


r*- 


DC 
O 

uj b 
Q- < 
O Q 

: x 

■■ sr 


o 


o 
■c 

0) 

£ 

TO 
Q. 
< 


o> 


CD 

5 


(O 


TOTAL CREDIT 

ENTRY DOLLAR 

AMOUNT 


2 


v> 
69 
69 
69 

69 
69 

SI 

69 


8 




tft 


TOTAL DEBIT 

ENTRY DOLLAR 

AMOUNT 


.■ s 


' . ■ ■ . t». 
t*. 
69 
69 

69 

69 

49 
69 
69 
69 
69 
69 
69 
69 
69 
69 
69 
69 
69 
69 


o 


o 

J 

CM 


* 


II 

in x 


2 


4) 

£ 

z 


o 


o 

CM 


CO 


ENTRY/ 

ADDENDA 

COUNT 


2 


'C 
0) 

E 

■'.'■ 3 


tO 


o 


CM 


SERVICE 
CLASS 
CODE 


. 2 


a 

■ 'C 

a) 
E 

■ . ■ ■ ^ 
. Z 


to 


? 

CM 
O 


■-; 


RECORD 
TYPE 
CODE 


2 


■ ■ 9° 


- 


o 

O 














o 

-i : 

LU 
U_ 


DATA 

ELEMENT 

NAME 


Field 

Inclusion 

Requirement 


8 


■c 
c 
-J 


c ■ 
.o 

Si 



a 

DC 

o 
o 

LU 
DC 

IS 

LU 
Q 

£ 

K 

Z 
LU 

> 

a 
< 





UJ 












7 LU Z X 
Ul CQ X P 




o 
<u 




s 






ZS 


. £ 




^. 






z 




O) 




« 










•V 


JULIAN DATE 

ON WHICH 
THIS ADVICE 
IS CREATED 


■' ; 5 


o 

■ 'C 
OJ 

E 

■ 3 

z 


CO 


o 
o> 

CO 




DC 












OKjO 




5 








z lu n h 




5 




f^- 


CO 


2 


i- 


CO 






BCz9 o 




1 




.. 


CM 


ADDENDA 

RECORD 

INDICATOR 


5 


o 
E 

2 


>- 


3; 

r- 


.*- ■ 


oc < S 


O 


o 

! 

ro 


CN 


co 




«OQ 

Q F ■ ■ ■ 




x: 
a. 
< 




r» 




' ■ -i 
< 












3 UJ 




(U 






o 


OS 


OC 


. E 




r- 




a z 


ra 

' JZ 

a. 


CN 


in 




z . 




< 








~* 












DC 












O 




. m c 






en 


ACH 

OPERAT 

DATA 


o 


at 
E 

CO 

JZ 

a. 
< 


:>■ 


3 
3 








o 






CO 


FILE 
IDENTIFI 
CATION 


o 


■ - c 
0} 

E 

I 
a. 

< 


■ t " 


S' 

c* 




■'■3 s [8 














■c 




CO 


r- 


'■lis 


2 


I 


ai 


o 




903 




■ u 
Z 




^r 








t*. 












t*. 








1- 




69 






<D 


z 

D 

o 


2 


69 
«/» 
69 


f^ 


CO 

c6 




< 




69 
69 
69 
69 
69 




CM 


u> 


DFI 
ACCOUNT 
NUMBER 


QC 


O 

•c 
a> 
E 

CO 

.c 
a. 
< 


m 


CM 
CO 


■* 


lu e> 

5 5 


2 


o 

■ 'C 

a> 

E 

■ 3 

z 


.-T 


CM 
CM 




o . 




.^f 








z . ■. it z 




2 






CO 


RECEIVI 

DFI 

IDENTl 

CATIO 


2 


1 


a> 


i 


CM 




2 


o 

•c 

E 


CM 


CO 

9 




ggo 








o 




a 












OC UJ LU 










*- ■ 


O o- Q 
UJ H O 


2 


to 


.'.r- 


o 










o 




DC 


























■ . ■ ■ ^ 












■ c 










K 


0) 










* 


■■ c S 


«i 






Q 

■ -1 
LU 


>»TA 

LEME 

AME 


sl'l 

,a) o 5 


p 


-c ■ 
c 




LL 


QIU2 


a: 5 q: 


O 


-J 


£ 



o/?^ 



2005 OPERATING RULES 



APPENDIX TWO 



n 



U 
JO 



© 

<2 



a 
o 1 

(/} 
IT) 



o 

H 
U. 

GO 

PQ 



Q 

o 
o 

HI 



UJ 
Q 

>- 

oc 

K- 
Z 
UJ 

o 

oc 
< 



r- 


y.M 


s 


o 

■c 
a) 
E 

z 


m 


■ ? 

o 

00 




Q 












It 
























uj O 




o 








£ 1- 








O) 


O 


UJ z 

a 


2 


£ 
z 








■■ >- ■ 












DC 












% 












o< 








CO 


en 


K Q 

o 
« 
5 


o 


5 

a. 
< 


<M 


f^ 
ri 
r- 




< 




o 








3 UJ 




0) 






CO 


a s 
> < 


o 


CO 


CM 
CM 






5 Z 




a. 




«■> 




z 




< 


















r- 


CHECK 
SERIAL 
NUMBER 


2 


o 

■c 

0) 

E 

S 
a. 

< 


*° 










■fc* 








H 




t*. 






(O 


z 

D 
O 


'■ ■ ■ s 




o 


CO 




s 
< 








CO 




z"* 

5 uj 

E « 

o 5 




o 






IO 


<z 


0) 

E 


s. 


■s 












< z 




< 






V 


St 

UJ o 

.:§.= 


2 


O 

■c 

1 

z 


.'■- 


CM 
CM 




— z 












*°: 












o$ 




5 






« 


z o 
> il 

UJ \- 

o z 

UJ UJ 


s 


£ 


CO 


■4 
o 




. z . . 












o 












p ... 




o 








o sy 




•c 




CO 


CM 


So 


. s 


£ 


CM 


9 

CM 




z ° 




z 




o 




1- 












Q 












DC UJ UJ 










*- 


O a- Q 
UJ K u 


5 


SP 


.;«- 


o 










o 




DC 














_ 












c 










K 


<b 










? 


c E 


60 






Q 
-J 

UJ 

u. 


s9>& 

K Uj 5 

S H 3 

QIU2 


£5« 


■ c 


-J 


$ 




OR 49 



APPENDIX TWO 



2005 OPERATING RULES 




4> 








Im 




+-» 




a 




H 


a> 


Pi 


(0 


pq 


L. 


U 


o 


I* 


1« 


<2 


o 


V) 


o 


T3 


'^■^ 


O 


Q 


Qi 


4> 

o 


O 
o 

LU 


<u 


tt 


a 


_J 


3 


< 


a 


h- 


<w 


LU 


</> 


Q 


^c 




7H 


£ 


r4 


of 


£ 


z 


O 


LU 


H 


oi 


U 


so 


W 


o 


cfl 


' 


ffl 




& 


■ . ■ . . 


C/3 


■ . ■ 



- 




2 


O 

•c 
£ 
z 


m 


6 

CO 


o 


ADDENDA 

RECORD 

INDICATOR 


2 


o 

CD 

e 

z 


'*" 


a> 




. >- . 












cc 












< 




o 








z 










o» 


S2 

kg 

o 

CO 

a 


O 


cu 
E 

CO 
jC 

Q. 
< 


CN 


CO 




>- . 












i 












a. 












2 




O 








o w 




0) 




CD 


CO 


°5 
O < 


oc 


CD 


CM 
CN 


iA 




z z 






in 




> 




< 








UJ 












U 












LU 












K 












Z 












O 












i- a 




'C 








< LU 




a> 








o co 




E 




m 


r- 


E2 


o 


CO 




o 




Si 

LU 




a 
< 




■* 




O 




























-t* 








J- 




-t*. 






to 


. Z 

. 3 

O 

2 

< 


2 




O 


C7) 
CO 
O 
CO 


in 


DFI 
ACCOUNT 
NUMBER 


o: 


a3 
E 

CO 

■ x: 
a. 
< 


f- 


o> 

CN 
CO 




St 




y 




CN 


^ i 


LU O 

5 5 


2 


£ 
z 




CM 




— 5 z 










<o 


RECEIVING DF 
IDENTIFICATIO 

OGO 
IDENTIFICATIO 


2 


1 


00 


4- 

O 




z 












o 












to o 




c 




CO 


CM 


2 


0) 

£ 


CN 


O 
CN 




zo 




z 




O 




JS 












H 












a 












DC uj UJ 












RECO 
TYP 
COD 


2 


to 




O 


















c 










k- 


CD 










s 


e- E 


■i2 






a 

■ -J 

LU 


DATA 

ELEME 

NAME 


Inclusio 
Require 


I 


1 

CD 

-1 


1 



0) 

CO 

l_ 

o 
a. 

t. . 

o 
o 

a 
a: 
o 
o 

LU 
< 

a 

z 

LU 
Q 
Q 
< 

QQ 
O 






S2o 

a: u 
0< 



UJ z 

a: 
O 



m 

II 

a. 2 
Z S 

UJ 
QC 
O 



iS 

o o 
BE 



a: 
o 



o UJ 
P Q 
oO 
<o 



:|8 

a 

Q 
< 



a a 
cu o 
Oo 



k uj £ 



§ I 
s 2 i 

it- ■£ .QC ■ 



OR 50 



2005 OPERATING RULES 



APPENDIX TWO 



a 
W 

Q 
U 
U 

o 



is 

a 1 

o 

l-H 

H 
U 

w 

PQ 
& 



& 
O 
O 
lu 

j 

.5 

111 

a 

I- 

■Z 
LU 

O 
O 

o 



- 


tug 

n 


5 


O 

£ 

z 


in 


8 




S'bS 




(J 






o 


ADDENI 

RECOR 

INDICAT 


2 


C 
0) 

E 
z 


■ T ~ 


O) 

IV 
a> 
rv 




■■>-■■ 












D£ 












< 












Z 












o< 




CU 

E 
a. 




00 


O) 


K Q 


O 


CM 


iv 
rv 




-.8. 




< 








Q 










00 


RECEIVING 

COMPANY 

NAME 


a: 


o 
c 
<d 
E 

re 

■■s. 

< 


/a 


CO 

iv 




Z 












O 












t K 




o 








< LU 




<u 




3 


r- 


o m 

LL 5 


o 


E 

(0 


\r> 




P2 








** 




z z 

LU 




< 








Q 




























'. ^t>. 








1? 










to 


3 

o 

E 
< 


.'.'■■'2' 




o 


op 
o 

CO 




.'■§* 




o 








ojy 




<D 






lO 


o g 


a: 


. E 


iv. 


C\l 




<3 












cc z 




< 








a 












Sb 




.y 




CM 


"* 




2 


E 
■ ^ 
z 




(N 




■*i 












o 5 










eo 


Ul 1- 

o z 

LU LU 

DC a 


s 


1 


oo 


■4 

O 




z 












o 












o£ 




'C 




CO 


<N 


rf a 
«o 


s 


■e 


CM 


O 




z o 








o 




■s.. 












H 












O 












a LU LU 








,_ 




RECO 
TYP 
COD 


s 


CO 




o 

O 






. 












c 










K 


CD 










5 


c E 


(O 






a 

-i 

HI 

El 


ELEME 
NAME 


Field 

Inclusio 

Require 


s 

1 


1 

CD 
-J 


! 



a 

LU 

_J 00 

II 

Q LU 

>- U 

DC Z 

h- LU 

Z 3 

iu a 



o 

yj 

a. 
< 

Q 

UJ 
O 
Q 
< 

O 
O 



« 



DO 

Z Z 

LU UJ 



a 

LU 

S | 
■ : »I 

, a: 
5fi> 



■S! 



LU 

I 1 



So 

Q LU 
Q £ 



LU 

a a 

QCO 
O O 
U uj 

lu k 



i- 55 5 
Q UJ % 



ill 

it- -so:- 




Oi? 57 



APPENDIX TWO 



2005 OPERA TING RULES 




a 
W 

W 

y 

ha 

.2 

o 



2 1 

00 



O 

H 
U 
W 

« 

P 



O 
O 
LU 

m 



LU 
Q 

& 

H 

Ul 
LU 
O 



T- 


Ujg 


2 


o 

'C 

£ 

3 

z 


in 


? 

o 

00 


o 


9d£h 

go< 

QUO 

< o: 2 


2 


o 

'C 

0) 

E 

3 

z 


'.- 






. > 












QC 












< 




(J 








z 










o» 


o< 

IS 
a-- 

5 


o 


to 
5 


CM 


co 




z 
















o 








D < LU 




o 




to 




O O CO 


2 


E 


CJ 


r- 


00 


Z** 

= HI 


ca 

Q. 
< 


CJ 






Q 
























- -J 












< 












3 UJ 




<D 




o 


h» 


OS 

Q z 


a: 


E 

(0 

x: 


in 




Z 




< 
























-a- 








Z 




ft 




O) 


(0 


3 


2 




O 


CO 

8 




t- 












Z 




CJ 








3 K 




E 

f 






w 




.<* 


r*- 


CO 




3d 






*r- 




■ _ z 

LL 




< 








o 












*H 




'C 




CM 




O — 




<D 






*r. 


UJ O 

■ 5 = 


2 


E 

■ 3 

z 




CM 




— z 












S2 




<r 








w< 




5 




*- 


*•> 


So 

> LL 

g z 


2 


i 


00 


•4 

o 




z 












o 












:|8 




o 






(M 


. 2 


i 

3 

z 


CM 


CO 

9 




.1 












Q 












OC UJ UJ 










*" 


On. D 

o >■ o 

UJ f- o 


2 


U> 




o 


















c 










K 


<b 










X 


c E 


w> 








2^ 

1— tu Sg 


■ -Q.fi 

,0) O 0) 

iC -£ ft: 


i 


o> 


,Q 


Ul 


3 H S 


■8 


-J 


« 



Q 

a: 
o 
o 

LU 

< 

Q 

z 

LU 
Q 
Q 
< 
UJ 

o 



-J CQ 
<2 



z r> 
ui o 



LU 
CO 

il 

LU UJ 

§ Z 

<s 

a 

LU 
(0 



■55 

is 



<M 



- LU 

|8 

UJ° 
Q UJ 

a o- 



UJ 

S8 

oo 

OuJ 



s : ii 

Q UJ* 



■ 0:g 

all 

0} o o 
LL 5 ft 



OR 52 



2005 OPERATING RULES 



APPENDIX TWO 



*C 
+>* 
a 

X 

H 
U 

•s 

o 
© 
s 

O' 



o 

H 

u 

w 

n 



Q 

a: 
O 

o 

LLI 

i* 

HI 
Q 

i 

z 

LU 

LU 

I 

o 

a. 
a: 
O 
o 

x 

o 





tugj 


s 


u 

■g 

E 

■ u 
. z 


IO 


3 

6 
00 




■■3 9 5 




u 








goo 

< a Z 








<n 


CM 


2 


■ E 

D 

z 


. " - 


IV. 

at 




~~ 












: >- . 












a: 












< 




u 








z 










^ 


oc Q 



« 

Q 





1 

< 


CM 


00 




a 












UJ 












> 




* 




CO 




a: 


<; 


. c 




1^ 




LU 


z 


CD 




.A 




(0 




co 




r»- 




LU 












a: 












w >• « fv 




u 






en 


RECEIVI 
COMPA 
NAME/ 
NUMBE 


DC 


E 


CD 








a 
< 




m 


CO 


NUMBER 

OF 
ADDENDA 
RECORDS 


5 




■■'S 

E 

■ z 


-* 


00 
in 
in 
in 














. ■ ■ z ■ 












O 












Fu 




O 






h- 


< LU 
O CD 
LL S 


O 


E 

CO 


lO 


'■■'? 





P3 




a. 




■* 




z z 

LU 




< 








Q 
















-0. 








H- 




•w. 






<0 




■ ' ■ S 


[1 


O 


O 
CO 



CO 




Z* 

5 LU 

Q i 
2 




"■? 






m 


oc 


£ 

CO 


r- 


CN 
J2 




< 2 




< 






* 


LU O 

S 3 


■'.■■' : s 




■c 

0) 

£ 

' Z 


- 


CN 
C\J 




: r- z 












S9 










w 


So 
> c 

LU K 

tig 


5 


1 


00 


4 
O 




Z 












O 












P ... 




O 








O g 




•c 




CO 


CM 


«o 


■ : -s 


i 


CSJ 


9 




zo 








O 




&■ 












*- 












Q 












a: lu uj 










. >- 


OD.Q 
o>- O 

LU 1- O 


s 


S° 




O 










O 




* 


























„_ 












c 










1- 


£ 










Z 


c £ 


« 






Q 

-1 
UJ 

in 


- -^c SN in 

ft S s 
§ul§ 


gj 

.01 O 

CSQ: 




-J 


1 



Q 

O 

O 

UJ 

a: 
< 

Q 

Z 
LU 

a 
a 
< 

X 

I- 
o 



in 


LU 

-J CO 

Si. 

LU Z 

Q uj 
>- O 
0£ Z 
h- UJ 
Z 3 
LU O 
LU 


2 



oi 
E 

. z 


■- 


00 

CO 


* 


a: 

UJ 
(0 

11 

LU LU 

<s 

a 

UJ 

W 


2 


y 
cu 

E 

z 


-* 


4 

co 


CO 


O 

LU 

z tt 
Lu O 

P 

D. 






to 

■ £ 

CO 
Q. 
< 



to 


CO 
CO 




01 


I§ 
go 

a lu 

a- 


2 


LO 
O 


<M 


CO 



CN 




r' 


LU 

a. 

.&„ 
§8 

O 
O 

LU 

a: 


'■'.'■.'■'S 


F^ 


- 


















Q 

-J 
LU 


■a 

diu$ 


Inclusion 
Requirement 


I. 


1 

a> 






0/?53 



APPENDIX TWO 



2005 OPERATING RULES 




vs 




4> 








1-1 




H-> 




a 




H 




W 




£ 




O 




u 


Q 


<2 


& 


c» 


o 




O 


© 


yj 


0> 


a; 


pa 


. . . *j 


<•* 

© 


< 


« 


H 


c-> 


UJ 




Q 



O 


■ & 


tf) 


h- 


o 


Z! 


T-H 


LU 


T-H 


UJ 



z 
o 

H 
U 

1/5 
PQ 






lei 

Q U O 

<*z 



9 2 



< 
3 UJ 

O 5 
>< 



. z 

< H OC 
D < UJ 
QUID 
>ES 

= UJ 



3 K 

o g 

«2 



St 

Ul O 

SB 



P 

> u. 

UJP 

a z 

UJ UJ 
<£ Q 



«8 



■.a 



O 

CC UJ UJ 

o 9- 9 
u >• o 
ui f-o 



-i £ g S 

u. QUJ% 



•il 



"33 "5 Qj 



o 

o 

UJ 

< 

Q 

UJ 
Q 
Q 
< 
UJ 

z 



to 


UJ 

■■-J CO 

Si 

UJ z 

Q QJ 

>• O 
DC Z 
K UJ 
Z 3 

ut O 

Ul 

« 


■.'■ ;s 


o 

E 
z 


h- 


co 

00 


<» 


OS 
UJ 
CO 

■Si 

Q Z 

a 

Ul 

w 


■'■■■ : s 


o 

■ 'C 

a> 
E 

D 
2 


** 


00 

i 


eo 


Q 
UJ 

ce < 
uj o 

p 

0. 


O 


O 

■c 

0) 

. E 

CO 
JC 

a. 
< 


O 
00 


CO 

op 
o 


w 


1§ 

Q UJ 

o a. 


■■';■' 2 ■ 


to 
p 


CN 


n 
o 

CNI 

o 


- 


UJ 
QQ 

cc o 
o o 

O uj 

uj a. 


. 2 


F- 


- 


o 

o 














Q 

_l 
UJ 


DATA 

ELEMENT 

NAME 


Field 

Inclusion 

Requirement 


V) 

c 

■ c 

■8 


■ -c 
c 

0) 


1 

'5) 

5 



CW54 



2005 OPERATING RULES 



APPENDIX TWO 



a 

z- 
w 

CO 

© 

© 

o 

©' 
«3 



© 

H 
U 
W 

« 



a 
a: 
o 
o 

UJ 

< 

UJ 

>-■ 

>- 
z 

UJ 

Z 
UJ 







2 


o 
cu 
E 

■ ■ u 
. z 


10 


6 

CO 


<N 


goo 

.9 a: h 

E o < 

a o o 


2 


o 
c 

<D 

E 

. z 


■:— 


a> 


- 


< 

z ■ 

O 
« 

Q 


o 


o 
(D 

: E 

TO 

.c 
a 
< 


CM 


00 

1^ 


O 


Q 
UJ 

UJ 

w 

UJ 

a 


z 


c 
CO 


CM 


to 
in 


o> 


il|.s 

SoSg 

So zz 


: '■ ■ ric 


o 

■c 

CD 

E 
:■■£ 

D. 
< 


to 


-<* 

<£ 
to 


CO 


ft Q g 

ifep 


: '5 


U 

• E 

■ . z 


•sr 


00 

to 

IT) 

in 


r- 


z 
O 

< UJ 
O CO 

E S 

£1 

UJ 

9 


o 


y 

E 

ca 

.c 

Q. 
< 


U1 


o 


(O 


z 

O 

. s 

< 


£ 


O 

o 
o 
o 
o 
o 
o 
o 
o 
o 


o 


CD 

co 
6 
<*> 


u> 


z"* 

^ UJ 

Si 


q: 


o 

•c 

0) 

E 

(0 
Q. 

< 


i^- 


CN 
CO 


<s- 


8t 

UJ O 

5 5 


2 


o 

"5 

E 

■ 3 

z 


■'■ - 


CM 
CM 


to 


z o 

> Gl 
UJ p 

o z 

UJ UJ 


s 


i 


00 


4 
O 


CM 


z 
o 

is 

■ ■ 1- 


; ' ■ S 


E 

z 


CM 


CO 
O 
CM 
O 


- 


Q 

a: uj uj 
O a. Q 
o >~ o 
uj y- o 


■'■.■ 2 


CO 


- 


O 
O 


a 

UJ 

DC 


Egg 

Q UJ Z. 


c 

0) 

■■§ 1 
5'11 


CI 

I 

8 


! 


| 
I 



Q 
OS 
O 
O 

UJ 
0£ 

■<■■. 

Q 

Z 

UJ 

z 

UJ 



in 


UJ 

SI 

UJ z 
Q m 
>■ o 
a z 

f- UJ 
Z 3 

uj a 

UJ 


2 


o 

■ 'C 

aj 
E 
i] 
Z 


r^ 


CO 
00 


<* 


Ul 
CO 

gi 

S3 

Q Z 

a 

UJ 

W 


^ 


u 

£ 
z 


•«* 


co 

s 


M 


Q 
UJ 
H Z 

5g 
^< 

2 DC 

uj O 
S £ 
>- 5 
< 

a, 


cn 


o 

ai 
E 

CO 

a 
< 


o 

00 


CO 

op 
4- 
o 


w 


g o 

Q UJ 


. : s 


Co 
p 


CM 


CO 
CM 

o 


> 


UJ 
Q Q 

oc o 
o o 

O uj 
UJ q. 


'■;'■' S 


f~ 


•- 


o 
o 


a 

j ■ 

UJ 

u. 


DATA 

ELEMENT 

NAME 


Inclusion 
Requirement 


is 

I 


t 

-J 


i 




OR 55 



APPENDIX TWO 



2005 OPERATING RULES 








•m 




ha 




-<-» 




a 




W 




W 




H 




S 




Sm 


Q 


a 


a: 


C/5 


O 




o 


o 


in 


0) 


a: 


tf 


_i 


Cm 
o 


< 


tu 


■■■■■:■!- 


o 


Ill 




a 


S 


■ >- 


a 


fc 


Cfl 


i- 


r^ 


z 


t-H 


UJ 


tH 


Ui 


<S 


1- 


£ 


2 


o 




>=* 




H 




U 




% 




<n 


■ 


ffl 




D 


; 


cc 


'. ■ ■ ■ ; 





iu£ 




■ ■ ■ 




-* 


. , ~ 




2 


e 

z 


in 


en 

00 




" dc fc: 



















en 


■ o 


ADDEP* 

RECO 

INDICA 


.2 


CD 

E 

z 


"" 


0) 














>- 












DC 












< 













z 




•c 






<n 


DC ° 

O 

« 

5 


O 


E 

(0 

■ .C 
Q. 
< 


CM 


00 




■ ■ z ■ 












jS 




Q 








< b oc 












3 < UJ 




<1> 




co 




D O CO 


.2 


E 


CM 


r*. 




INDIVI 

ENTIF 

NUM 


.c 
a. 
< 


CM 






a 
























-1 . 












< 












3 UJ 




Q) 




^r 


" 


D S 


5 


E 

to 

x: 

D. 

< 


m 


in 









t*. 






(O 


1- 

z 

O 
< 


2 


to 

8 





en 




K 












' Z 












3QC 




™ 








O 5 








en 


lO 


* 


CD 

ex 


t^ 


CM 
CO 




<=> 






. ^"" 




— z 

LL. 




< 








a 












Sb 




aS 




CM 


^ , 


UJ O 

5 3 


. . 2 


£ 

3 

z 




CM 




— z 












ng 












<j5 




s 




,_ 




Z O 










o 


uip 
z 

UJ uj 

os 


^ 


1 


00 


O 




z . 












O 












is 




(J 






evi 


2 


■c 

(U 

E 

ZJ 

■ z 


CM 


CO 

9 

CM 
O 




» 












1- . 

























OC uj UJ 












RECO 
TYP 
COD 


. 2 


CO 




O 


















c 










l- 


<D 










> . 


r- E 


w 






Q 
-J 

m 

UL 


DATA 

ELEME 

NAME 


Field 

Indusio 

Require 


1 


XT 

o> 

c ■ 
a> 


'5) 



&. 
o 
o 

UJ 

on 

< 
a 

z 

UJ 
Q 
Q 
< 
UJ 



CM 


uj 85 


■'■'. 2 




'C 

E 
. z 


in 


en 


CO 


- 


h 

Eg S 

1- 


cm 




£ 

CO 
Q. 
< 


CM 


en 
ctS 


O 


UJ 


cc 


O 

o5 
E 

CO 

n 

CL 

< 


in 


N- 
CO 
CO 


ci 


1 <E 
T3 


. o: 


O 

E 

CO 
< 


CM 


CM 
CO 
CD 
CO 


to 


' z 


1- 

O UJ 

< 5 

■■■$■ 
1- 


oc 


CO 
CO 

2 
2 

. ■ X 
X 


<D 


to 

CO 



CO 


r- 


z 


■is 


cc 


D 
D 

2 
2 


■* 


en 

CM 
CD 

CM 


(0 


TRANSACT10N 
SERIAL 
NUMBER 


DC 


CJ 

■ . 'C 
(U 

E 

CD 

x: 
a. 
< 


CD 


in 

CM 
CD 
CM 


« 


TERMINAL 

IDENTIFICATION 

CODE 


a: 


CJ 

■ ■ — 

£ 

■ sz 

CL 
< 


CO 


4 


^ 


NETWORK 

IDENTIFICATION 

CODE 





O 
O 

£ 

x: 

Q. 
< 


CO 


CO 


to 


is 

n 


fc 


O 

:"S 

E 
ro 

■ sz 
a. 
< 


h- 


O 

i 


n 


< 


2 


CM 
P 


CM 


CO 

9 

CM 
O 


■r 


Q 

OC UJ uj 

010 

UJ f- O 
OS 


2 


F- 


- 


O 
O 


Q 
-J 
UJ 
LU 


1- 

si SI 

1** Ui s 

Q UJ X 


<x> 

.0 $ 
all 

Q> O Q> 

iC £ Gt 


c 

Q) 
C 

8 


c 
-J 


■ C 

8. 



OR 56 



2005 OPERATING RULES 



APPENDIX TWO 



S 
PS 



© 

o 

C 

-3 



© 

H 
U 

W 

«< 

u 



E 

3 
(/> 

C 

o 
o 

Q 
DC 
O 
O 

OS 

d 
< 

UJ 
Q 

Z- 

UJ 

0£ 

so 
a, 



- 




£ 


'£ 

E 

z 


LT) 






Q 












a: 












8* 

uj O 




o 








tC H 








o> 


o 


ss 


^ 


E 


T- 


rj- 




D ~ 




3 








z Q 




z 








UJ z 












D ~ 












3 












>- 












0£ 












< 




o 








z 




~ 






o» 


og 

a: Q 

o 

to 

Q 


O 


£ 

CO 

SZ 
CL 
< 


CM 


00 




_j 












< 




™ 








3 UJ 










CO 


Si 

Q z 
Z 


a: 


. ' E 
to 

CL 
< 


tN 
CM 


r- 

ID 

m 




z . 












_i2 

< H 0£ 




O 








Z> < UJ 




o 




o 


h- 


QUO 


o 


b 

to 


W 








* 




•^ 




W 




< 








Q 




























■**- 








1- 




t* 






(D 


Z 

o 


£ 


«l0 


O 


CD 
CO 




s 
< 




tO 




CO 


IO 


DFI 
ACCOUNT 
NUMBER 


a: 


o 

'C 

to 

< 


(^ 


CM 

i. 


Tf 


St 

uj O 
5° 


5 


o 

0) 

E 
z 


- 


CM 
CM 




r- z z 












d2 9 




^ 






CO 


RECEIVING 
IDENTIFICAT 

OGO 
IDENTIFICAT 


2 


j 


CO 


O 




z 












o 












' F „, 




o 








So 




•l_ 




CO 


CM 


2 


E 


tN 


9 
CM 




zo 

■5: 




z 




O 




»- 












D 












K UJ UJ 










*- 


Ol O 

<-> h ° 

UJ f- o 


5 


tp 




O 










O 




a: 


























■»w 












c 










^ 


a> 








D 


DATA 

ELEMEN 

NAME 


Inclusion 
Requirem 


(0 

1 


C 


1 


tu 
u. 


5- 


~J 


$ 



CD 

E 

3 
CO 

c 
o 
o 

a 
a: 
o 
o 

UJ 

a: 
< 

Q 

z 

UJ 
Q 

a 
< 

QQ 

a. 



00 


uj£ 

■8" 


2 




•c 
a) 
E 

3 
z 


in 


8 




w _^ 












UJ^ 











h- 


Si 

UJ z 


. ■ ■ DC'. 


0) 
E 


in 


O) 




z| 




x: 

D. 




LO 




«o 




< 








HI o 












£o 












■.a< 












UJ 












o 












$< 












H UJ 








Tl- 


<0 


il 

o 
u. 


O 


£ 

. 3 

z 


CM 
CM 


to 

CO 




1- 












■ ■ z 




t*. 








UJ 




■w- 








s ^ 












>■ t 












<z 








CM 


in 


£3 

z2 


01 




in 


CO 
CO 




2^ 

UJ ^ 

a: 












o 




t& 








U_ 
























U. 












o 












o z 












^o 












>P 













UJ < 




a> 






^ 


o o 

y ui 


QC 


b 

CO 








*p 




a. 









z z 




< 








O ui 










Si 2 












a: 












O 












u. 












UJ 












£ 












z 




tj 








O UJ 




CO 




CO 


« 


Go 
50 

to 

z 

■S 


cr 


E 
at 

■ x: 

CL 
< 


CO 




4 





UJ 












Q. 












& , 










CM 




s 


O 


CM 


CO 

9 

CM 










O 




a 












Q 












< 












UJ 












0. 












■t. 












Q D 

ce 
00 


UJ 


2 


N- 




O 
O 


















. . H- 












c 










t- 


Q> 










■ a ■■ 


c- E 


to 






a 

Ul 
U. 


^ Uj 5 
3 2 S 

Q UJ Z 


Inclusio 
Require 


■ C 

CD 

I 


1 

qj 
^J 


1 




OR 57 



APPENDIXTWO 



2005 OPERATING RULES 




a 
w 

o 
a 

© 



GO 



© 

i— < 

H 
U 

w 
n 



Q 

9£ 
O 

o 

LU 

'X 

LU 

a 

■fe 

:i- 

z 

LU 

a. 
o 

a. 





u UJ 

Offl 









•* 


« 


: 2 


a) 

. E 

z 


LO 


6 


C4 


ADDENDA 

RECORD 

INDICATOR 


' ■ s 



ai 

. E . 

. D 

z 


- 


O) 




>- 












K 












< 













Z 












o< 




a> 

E 

03 

JC 
CL 




00 


r.' 




O 


CN 






u 




< 








(0 
























a 












* 












=> LU 




<I) 




CO 




Q 2 


O 


E 


CM 


h- 




a z 




<N 


in 




z 




< 




















ie 






•£= 

d) 
E 

CO 

x; 

CL 




s 


O) 


s2 


2 


CN 


CO 
1X5 




t- 




< 








_J 




(J 








< 










CO 


l£ 


2 


E 

TO 


■* 


CM 

in 




a: o 

LU 




CL 




■* 




■ H ■ 




< 








_J 












< 




O 








LU UJ 




CD 




co 


r- 


W ffl 
*2 

o 5 

LU Z 

r 
o 


.. 2 


£ 

TO 

x: 
a 

< 


O 











•». 








H 




t* 






<0 


■ Z 
3 
O 


2 


<« 
m 
*» 
w 


O 






s 




& 




(*> 




< 




;.$ 






"> 


DFI 
ACCOUNT 
NUMBER 


CC 




. "C 

£ 

TO 
CL 
< 


h- 


CN 
CO 




St 




O 




CM 


^r 


LU O 

55 


2 


E 
z 




CM 




\l. z 












S2 
9< 




5 








z 










CO 


> E 

UJ h* 

z 

UJ UJ 

a: a 


2 


1 


CD 


O 




z 












O 












So 















■ 'C 




ro 


O* 


2 


E 


CN 



eg 




zu 




z 









D 












o; tu lu 










, ™ . 


> O 
iu f- 


. : ■ : 2 


to 
























■ c 










^ 


03 










> . 


c- E 


Co 






a 

_j 

LU 
LL 


DAM 

ELEME 

NAME 


Field 

Inclusio 

Require 


c 
■Si 
c 

5 


c 

Q) 


c 


■fi 



OR 58 



2005 OPERATING RULES 



APPENDIX TWO 



4> 




•mm 




%m 




+* 




a 




w 




C/> 




O 




Cm 






a 
a: 




o 
o 


O 


Hi 




a: 


« 


_i 


««m 




o 


< 


a> 


h--:. : 


d 


Ul 
Q 


3 


>- 


a> 


K 


</> 


1- 


iri 


Z 


• 


Ul 


S5 


(0 

o 

Q. 


o 




NN 




H 




U 




w 




CO 




« 




P 




CO 







tug 

3 s 


2 




I 


w 







F 3 

z 




.'Z 




CD 




goo 
9 a H 




y 




O) 


o 


go5 

qO O 


2 


CD 

E 

. z 




01 




Z 












O Ul 












CD 

QnO 




'S 




00 


o> 


CAR 

TRANSA1 

TYPE C 


s 


. £ 

t 

< 


CM 


1*1. 




- _i 
< 













3 UJ 




a> 






CO 


Q 5 

Q z 

z 


a: 


E 
to 

x: 

CL 
< 


CM 
CM 


ui 




z 
















(J 
"g 








3 < UJ 






3 




do m 





f- 






>llS 


CO 

.C- 
Q. 









ig^ 




< 








Q 




























'.' t* 








l» 










to 


. Z 

o 


2 




O 




CO 




5 
< 








CO 




1- 












£*. 




O 








o w 




CD 




01 


u> 


o m 
OS 


cc 


E 

CO 


r- 


01 

CO 




O 




Q. 








a:^ 




< 








o 










V 


■St 

ui O 

55 


5 


O 

. w 
<D 

E 

. z 


■■:'- 


CM 
CM 




— z 
















5 








z 










w 


> ul 

as 


2 


1 


CO 







Z 












O 












So 




O 

■ -c 




CO 


cm 


2 


E 


M 




CM 




zo 




z 









S 












i- 












Q 












a: uj ui 










«-■ 


o>-o 

UJ h- 


2 


CO 


>- 


















0£ 


























H- 












c 










■£■■ 


,£ 


to 






a 

-1 
tu 

a: 


DATA 

ELEME 

NAME 


Indusio 
Require 


I; 


1 

-J 


1 



Q 
K 
O 
O 
UJ 

< 
G 

UJ 
Q 

a 
< 
w 
o 

0. 



CM 




2 


,0 
ai 
E 

z 


to 


3 


T* 


is 

1- 


q: 


.y 

ai 
E 

CO 

x: 
a. 
< 


CM 


06 


O' 


3 
i 

Ul 


ct 




1 

CO 

■ J2 
a. 
< 


tf> 


to 


a» 


II 

s < 
a: 
ui 

h- «J 


a 




■c 
a) 
£ 

CO 
Q. 
< 


CM 


CM 

to 

CO 
CO 


» 


_ HI 
Z Q h- 

q: < 
P < 
< z 

5 O E 

<°2 





O 

a) 

£ 

x:- 
a. 
< 


to 


Ul 
CO 


r- 


■ : z ■ ' ■ 

II 


a 


Q 
Q 
2 

5 


'tJ- 


o> 

2 

CM 


u> 


►=-■(5 


a: 



o5 
E 

CO 

■ sz 

CL 

< 


<0 


CM 
O 
CM 


•*> 


Z . 

5 s: 

UJ^U 
K Ul 

a 


cc 




■c 

E 
'.Jg 

CL 
< 


(D 


CD 
4 


* 


Ul DC 
u- O 

a z 


O 


.y 

ai 

E 
m 

x: 

CL 
< 


CO 


CO 


**> 


o| 

Ul < _ 

ass 

Ul DC 
"- O 


O 


O 

■c 

CD 

E 

00 

■ -C 

a 
< 


. . h- 


O 


CM 


< 
Z^^ 

< 


s 


3 


CM 


CO 



CVJ 

O 


- 


a 

at ui uj 

0?- O 

Ul H O 


2 


F^ 


- 


O 
O 














O 

■ -1 

Ul 

UL 


§5i§ 


■■'■' s 

-If 

■5 ^ A 

ll. .£ o; 


C 

5 


! 

-J 


1 




OR 59 



APPENDIX TWO 



2005 OPERATING RULES 




o 





a 1 

GO 

so 



© 

H 
<J 
W 

1/5 

M 

P 

<Z3 



Q 

o: 

O 
O 

LLJ 



m 

Q 

H 

UJ 
Q 

a, 
a. 



- 


nig 

■ M 


2 


■ ■ -c 

(D 

E 

3 

z 


m 


o 

CO 




Q 












a: 












R* 












uj O 




(J 








CC H 








o> 


o 


S" 


2 


£ 


^ 


r- 




Q ^ 












a: 9 




z 








ui z 












Q ~ 












Q 












< 












>• 












a 












< 




o 








z 




■. . -c 






oy 


5? 

oc Q 
o 
{/> 
a 


o 


CD 

E 

CO 
sz 
a. 
< 


C\J 


00 




< 




o 








=} UJ 




0) 




CD 


BO 


Q £ 


o: 


E 


CM 


r- 


o z 


CD 

sz 
a. 


CM 






Z . 




< 




















z 












<h- a: 




o 








D < UJ 




CD 




■? 
6 


r- 


Q O 00 

>E5 


o 


b 


in 




lii 

= UJ 




< 




■<* 




a 












~ 
















t*. 








t- 




-*». 






«> 


z 
o 


2 




o 


CO 




2 
< 




<*> 




CO 


W 


z"* 

S UJ 

Q o i 

,8* 


& 


o 

■c 

E 
to 

.C 

a. 
< 


h- 


CO 


.* 


St 

UJ O 

S 5 


s 


o 

CD 

:■ E 
. z 


> 


CM 
CM 




— z 












\° 




<; 








o5 




5 




i— 




z o 










«*> 


> K 

UJ p 

o z 

UJ UJ 


2 


E 


a> 


o 




z 












o 












H ... 




o 








5 o 








CO 


tN 


2 


a) 
E 


CM 


o 

CM 




zo 




Z 




o 




£ 












H 












Q 












Q£ UJ "J 












O0.O 

o >~ o 

ujf-o 


s 


s° 




9 
o 


















c 










K 


Q> 










e 


■ ' c £ 


« 






Q 

UJ 


5 SiS 

K Uj 5 

<* 3 <* 


.0 £ 
cd u a> 


c ■ 
Si 

■ c ■ 
o 




1 

to 


u. 


Q UJ Z 


(£5 0: 


O 


-J 


CL 



Q 

q: 
o 
o 

UJ 

< 

UJ 

a 

Q 

< 

Q 
0- 



m 


a: 

UJ 

-I to 

■■?§ 

Ui z 
D UJ 

>• o 

a: z 

h- UJ 
Z =3 

uj a 

UJ 


2 


O 

£ 
z 


N- 


CO 
CO 


■^r 


UJ 

m 

UJ UJ 
Q O 
Q Z 

<s 

a 

UJ 

to 


2 


Q) 

E 

. z 


"* 


4 
co 


rt 


a 

UJ 
uj O 

P 

a. 


O 


cB 

E 
ro 
x: 

Q. 

■;.< 


O 
CO 


CO 

oo 
4 
o 


CM 


I§ 

UJ u 
Q UJ 

o S- 

■;<fc 


5 


in 
p 


CM 


CO 

o 

CM 

o 


- 


UJ 

a a 
ao 
oo 

U ui 

ui a. 

■■*t 


2 


h~ 


- 


5 

o 














a 

_j 

UJ 

u. 


DATA 

ELEMENT 

NAME 


Field 

Inclusion 

Requirement 


i2 

. c '■■'■ 

8 


c: 

CD 

-j 


1 
1 



OR 60 



2005 OPERATING RULES 



APPENDIX TWO 



a 

u 

o 

© 

a 
<u 

a 1 

GO 



© 

H 
U 
N 

<Z) 

P5 

P- 
CO 



a 
oi 
o 
o 

UJ 

a: 

_! 

:f 

UJ 
Q 

I- 
LU 

O 



*" 


uj£ 

Si 


'■ 2 


o 

'C 

a) 
£ 

. D 

. z 


to 




o 


ill 

Q U O 

« 2 


5 


o 
a5 

E 
z 


r- 


cr> 


a> 


< 

■fiS 

« 

5 


o 


o 

■ - c 

£ 
ca 
x: 

Q. 

< 


CM 


00 


00 


_l 
< 

Z> UJ 
Q £ 

. z . 


a 


o 

■c 
a» 

E 

CO 

■ -C 

Q. 

< 


CM 
CN 


to 

lO 


r- 


< 

LU UJ 
CO CQ 

*5 

o 2 

UJ z 

u 


■ ■ ^ 


o 

. 'C 

a> 
E 
ca 

JC 
Q. 

< 


m 


o 


<0 


z 

. D 

o 

. 5 
< 


. : 5 


to 


o 


CO 

8 


IO 


1- 
o £ 

■SB 

Q 


.' ■' fc 


o 

■ 'C 
<D 

E 
ca 

< 


r- 


cm 

CO 


^ , 


uj O 
S5 


s 


y 

E 
z 


'.- 


CM 

CN 


CJ 


'■g< 

z o 
> IE 
w P 
u z 

UJ UJ 

a: q 


. s 


i 


00 


4 
o 


OJ 


■ z ' 
Q 

is 


s 


o 

E 

■ ' D 

z 


<N 


CO 

o 

CM 

o 


.-'■ 


O 

o: uj uj 

OQ.Q 

o >- o 

UJ t- o 


2 


CD 


- 


9 
o 


a 
_j 

UJ 

u_ 


sal 

d uj $ 


1 

C-Stt: 


jo 

I 

1 


1 

0) 
-J 


1 




OR 61 



APPENDIX TWO 



2005 OPERATING RULES 




.52 

a 

ffl 
u 



© 

PS 



a 

a* 



© 

H 
U 

W 
{« 
PQ 

£> 

(Z) 



Q 
DC 
O 
O 
UJ 
0£ 



< 
H 
UJ 
Q 



UJ 
OS 

CO 





uiffi 




.y 




-3- 


CM 




2 


E 

3 
Z 


ur> 


o 
o 

CO 


- 


ADDENDA 

RECORD 

INDICATOR 


. . .5 


.y 

E 
z 


.'■r 


en 




z 












o w 












CARD 

NSACTI 

PECOD 




■c 




co 


O 


2 


E 


CM 






it 












•- 












NDIVIDUAL 

CARD 
ACCOUNT 
NUMBER 














■- 




to 


en 


K 


<u 
E 

z 


CM 
CM 


















h- "J 












zoo: 












LUZUJ 




™ 




-* 


CO 


OCUM 
EFERE 
NUMB 


a: 


E 


£ 


4- 






z 




-r 




a a: 












z 












o 










r- 


D j- UJ 

DC <r H 
< 2 < 


a: 


£ 

2 


TT 


co 
o 




OElO 




S> 




T 




.3 
















-«. 








h- 




-». 








Z 
3 


2 


to 


O 


CO 


co 


o 


tf> 




o 




s 








CO 




< 












1- 












. z 












^a: 




■c 








OUJ 
o g 




0) 




a> 


v> 


cc 


E 

CO 

.c 
a. 


tv. 


CM 
CO 




< ID 






t ~ 




— z 

u. 




< 








a 












?3b 




o 

■c 
a> 




CM 


-* 


uj O 

55 


2 


£ 

3 


r* 


CM 






z 








. — Z 












feg 












oS 




5 








Z o 










CO 


at h 
o z 

UJ UJ 


2 


$ 


00 


O 




z 












O 










CM 


« o 


2 


o 

ai 

E 


CM 


CO 

o 

CM 




zu 




z 




O 




s 












l_ 












Q 












QC uj UJ 










■T- 


RECO 
TYP 
COD 


2 


s° 


^ 


O 
O 


















c 










K 












Z 


c E 


O 






D 

_l 
tu 


2?!H 

«* -J <* 


2 5 o- 
0) o £ 


c 
o 


1 o> 

1 c 




Li. 


QUI? 


LL £ DC 


O 


1 -J 


a. 



G 

a: 
o 
o 

UJ 

< 

Q 

z 

UJ 

Q 

O 

■<■ 

a: 
x 

CO 







kS 













CM 


pi 

V z 


2 


. E 
z 


10 


CO 
O 
00 






_j 













-; 


Is 


0^ 


■■c 
a; 
E 

ra 

■ x: 
a. 

< 


CM 


06 






_i - 




u 










< 




■ -L. 








o 


n 

UJ 


% 


E 

CO 

a. 
< 


ID 


CO 
CD 






_l z 




u 










■Sg 




0) 

E 




CM 
CO 




o» 


s < 

a: o 

UJ o 

i- _j 


&■ 


CO 

< 


CM 


CO 
CO 






^ Q K 














Oa< 














K < O 













CO 


AUTHORIZA 

CODE OR C 

EXPIRATION 





tu 
E 

03 

cx 

< 


CD 


CO 
O 






z . 



























K 


VIS 

1- 


DC 


a 



2 


■* 


CM 
(D 
CM 






z 














■ 













to 


RANSACTI 
SERIAL 
NUMBER 


^ 


E 

CO 

■fs 


CO 


IO 
CM 
6 








< 










H 














Z 














O 














MINAL 
FICATI 
ODE 




ai 




a> 




u> 


' ■. K 


E 

CO 


<P 


4 






ft c: u 
£z 

•" UJ 




Q. 
< 










a 




























wo 




O 

■c 

QJ 








«tf 


Sis 

UJ Qi 
u. 

Uj LL 


O 


b 

-.2 

Q. 


CO 










< 










a: z 














— 














o2 




O 










z t 




a> 










UJ < 




E 

CO 








CO 


KS« 


O 


h- 


' 






UJ DC 




.c 










u. 














"J U. 




< 










a: z 














— 














< 














Q UJ UJ 








CO 




CM 


ADDEN 
TYP 
COD 


2 


CM 
O 


CM 


O 
CM 
O 


















a 














a: hi uj 












T - 


RECO 
TYP 
COD 


■' 5 


t- 




O 
O 






















c 












k ' 


en 












e 


t- E 


<o 








Q 

_l 


k m 5 


lusio 
quire 




CD 


.9 




u. 


|s=j§ 


l <o ai 


8 


CD 
-J 


£ 



OR 62 



2005 OPERATING RULES 



APPENDIXTWO 











u 




s-» 




fl 




H 




J 




H 




"H 




o 


Q 


^ 


a: 




O 


Sm 


o 


© 


UJ 


W 
^ 


a. 


& 


_j 


«*N 




© 


< 


<u 


t- 


■ a 


UJ 


£ 


> 


<t> 


■ ■ ' * 


c/a 


1. H 


©N 


2 


T-f 


UJ 


¥*H 


_J 


r4 


UJ 


Z 


H- 


o 




*™ 




H 




U 




^ 




</3 




tf 




5 


■■'..- 


Cfl 







H! IS 




o 


" 












"St- 


▼- 


a £Q 


2 


(D 

E 

■ u 

2 


U) 


o 

CO 




o 












a: 












UJ O 




o 






o 


< o 


^ 


CU 

£ 


y- 






a — 








r- 




2 Q 




2 








a 












a 












< 












>- 












a: 












< 




o 






(ft 


■lis 

DC D 

o 

CO 

Q 


o 


(D 

E 
to 

.c 
a. 
< 


CNI 


co 




_J 




„ 








< 












3 UJ 




Q> 




to 


00 


a s 

z '■ 


cc 


E 
to 

■ n 

Cl 
< 


CM 
CN 


uS 

in 




■ ' 2 ' 












j2 













< t * 












D < UJ 




0J 




** 




a o m 


o 


E 


in 


in 




INDIVl 

ENTIFl 

NUM 


TO 
SZ 

Q. 
< 




o 

■■3- 




Q 












_ 
















t*. 








2 








a> 


to 


o 
< 


£ 




o 


CO 

8 


to 


DFl 
ACCOUNT 
NUMBER 


a: 


O 

E 
to 

.c 

Q. 
< 


r- 


CM 
CO 




St 








CM 


<tf 


UJ O 

5 5 


s 


E 
2 




CM 




■— 2 












ng 












?5 




§ 




■ 




2 O 










«*> 


> \L 

UJ H 

2 
LU UJ 

01 a 


2 


1 


co 


o 




z 












o 










CM 


■ is 


'■' ■ S 


o 

0) 

E 

■ rj 

. 2 


CM 


CO 

o 

CM 
O 




Q 












cc in tu 












RECO 
TYP 
COD 


S 


CD 




O 






^ 












c: 










!-. 


0) 








a 

-J 




lusion 
auirem 




■ 






** -j ■* 


a> o aj 


o 




o 


u. 


duls: 


Cl 5 tc 


O 


-J 


0. 




Ort53 



APPENDIX TWO 



2005 OPERATING RULES 




a 

u 

H 

o 



0> 

G 
a 1 

O 



© 

H 
U 
W 
1/3 

M 



Q 

a: 
o 
o 

LU 

a: 



UJ 

a 



UJ 



fM 


tug 

M 


2 


o 
*c 

1) 

E 
z 


^ 


6 

CD 




SgS 




o 






^ 


=J OC h- 

182 

1*1 


5 


■i_ 

(D 

E 

3 

z 


T- 


0) 




uj a 












Q. o 










O 




P 


CD 

. E 


CN 


00 




tu a 




a. 








t z 




< 








■s« 




o 






o» 


|S9 


■ .' ^ 


<D 

£ 


CD 


CO 




Cjo 3 








CO 




E z 




< 








CO -1 




u 






a 


CO O Q 

oh d 

OZ £ 


a: 


o 

E 
aj 


CD 


o 

CD 
IT) 




oco "■ 




CL 








o-o 




< 






r- 


^ -J Sj 

ujk i 
X uj ^ 

o to | 


o 


ai 
E 

CO 
JC 

Q. 
< 


W 


in 
6 








-«. 








h- 




t*. 








Z 
3 
O 

< 




» 




en 


to 


2 




O 










feft 








1- 












§* 




O 








o £ 




0) 




0> 


IO 




q; 


E 

CD 


r*- 


CN 
CO 




<2 












lT^ 




< 








a 










<» 


■fib 

IU (D 


5 


a 

1. 

z 


> 


CM 




;r z 












fcs 




. 






to 


5 <-> 
> c 

LU j= 
o z 

LU LU 

a: a 


5 


1 


oo 


4 
o 




z 












o 












p ... 




o 








o jy 




c 




CO 


est 


So 


s 


E 


<N 


% 




z u 




z 




o 




1- 












Q 












K LU LU 












O0.Q 
u >- o 

LU H O 

a: 


2 


to 


*~ 


o 
o 






■ 












c 










>>- 


ai 










Z 


c E 


CO 






a 

LU 
U. 


S H S 

Q Ui Z 


.03; 

ill 


1 


1 

CD 

-J 


1 



OR 64 



2005 OPERATING RULES 



APPENDIX TWO 



a 



a 

u 
o 



D 

a 1 



o 

H 
U 

W 

« 



Q 

oc 
o 
o 

UJ 



Q 

> 

OC; 

LU 



M 




2 



•c 

<D 

E 

3 
z 


m 


■? 



00 




goo 
9 ac h 

< * z 















'l_ 




O) 


CM 


: s 


(1) 
E 

. . z 


. . , ~ 


O) 




— 












uj a: 













0. O 










- 




O 


E 
cd 


CNI 


GO 




lu a 




a 






>z 




< 








Q 












LU 












> 




^c 




to 


O 


a: 

LU 


z 


c 
co 


CM 






to 




CO 




f- 




LU 












QC 












^c« 











O) 


tiog| 

So zz 


^ 


E 

CD 


<D 


O) 






< 




10 




^ Q LU 

z ■ . < DC 










CO 


2 


E 
z 


•^r 


00 
in 
in 
10 














z 












o 












H DC 













< LU 




CD 




3 



r» 







fc 
(0 


in 




F5 




a 




-* 




z z 

LU 




< 








D 




























T*- 








■ K 




t* 








-J z 




6ft 






■* (D 


: M 


2 


6ft 
6ft 
6ft 
6ft 
6ft 





CO 



CO 






69 












69 






OT 


§ LU 

Egg 

3 s 


^ 


O 

■ ~ 

I 

CD 
< 


h- 


01 

CNI 


^r 


LU O 

.■■'■o° 


2 


£ 

■ 3 
. Z 


'.'■'" 


CM 
CM 




— z 












S° 




<; 








Z o 




| 




- 


cs 


> Lt 

LU H 
O z 
LU UJ 


2 


1 


CD 






■ z 












o 












1 — ... 













So 








CO 


CM 


■ ■ ' / 2 


a) 
E 


CM 




CM 




z o 

2 




Z 




O 




H 












o 












Lt LU UJ 












O >" O 
LU r- O 

a ■'.' 


2 


i° 


' 


9 
O 






■ ■ ■'*-■' 












c 










h- 


CD 










2 


c E 


■i2 






Q 
_] 

LU 

LL 


2^ 

►— LU * ■ 
«t *J <t 


5 

.0 (3 S 


c 

. ■■ c . 

.3: 


■ '-J 


i 



o 
on 
o 
o 

LU 
DC 

< 
O 

z 

LU 
Q 
Q 
< 



« 


a: 

UJ 

_i m 

P3 
LU Z 
O uj 

>u 

DC Z 

H LU 

Z 3 

UJ Qf 

LU 

(0 


2 




is 

■ ■£ 

: 3 
2: 


r^ 


00 
00 


n 


a: 

LU 
CD 

ii 

LU UJ 

DO 

2 


2 





E 

■ 3 
. z 


■<* 


op 
00 


n 




LU 

n 

5 DC 

Lu O 

a. 


O 




a3 

E 

(D 

.C 

cx 

< 



00 


CO 
CO 




CM 


. LU 

Q LU 


2 


in 
p 


CM 


CO 

9 

CM 
O 


y- 


LU 

a 

DC 



O LU 
LU CL 


:' 5 - 


r^ 


> 


O 
O 


Q 

_j 
LU 
LL 


DATA 

ELEMENT 

NAME 


Field 

Inclusion 

Requirement 


s 


CD 
—1 


5 

2 




OR 65 



APPENDIXTWO 



2005 OPERATING RULES 




O 

MM 

H 
U 
W 
</} 

p 



Q 

O 
O 
LU 

o: 

LU 
Q 

I- 
Z 
UJ 

CO 
LU 

5 





gS 








rf 


1 


^ z 


2 


0) 

e 
z 


m 


a> 
6 

GO 




o 












at 
























uj O 




o 






o 


*5 

So 


2 


. E 


■'.,- 


O) 
CD 




Q == 




. D 








z 9 




z 








s* 






.'._ 






§ 










o» 


PAYMENT 
TYPE 
CODE 


fc 


I 

< 


cm 


00 




:* 




o 








3 UJ 




a> 




to 


eo 


Q Z 


* 


E 
to 

x: 
a 
< 


CM 
CM 


in 




z . 












jO 




o 








3 < LU 




a) 




b 


i— 


a o m 


o 


b 
to 


m 




iii 

£ LU 




a. 




Tf 






<: 








a 












. _ 
















■w. 








£ 




w 




O) 


(O 


3 

1 


s 


1 


o 


;3 


u> 


DFI 

ACCOUNT 
NUMBER 


a: 


I 

a. 
< 


r^ 






>»b 




o 

■ - c 




CM 


■*.■ 


LU O 

5 5 


2 


E 
z 




CM 




- Z 












2p 




3 








o< 




3 




,_ 




z o 










w 


5E 


2 


j- 


00 


s 




LUP 




F 






o z 




t 








sis 
























■ z . 












o 












og 




i 




CO 


CM 


S5 o 


2 


cm 


9 

CM 




zu 




' z 




O 




§ 












1- 












Q 












£ LU LU 












RECO 
TYP 
COD 


. ■ 2 


CO 




o 
o 


















^, 












c 










K 


CJ 










. z . 


c E 


V} 






Q 

_l 
UJ 


h- LU * 


o 5 


c 
p 




c 
.o 


u. 


QU1% 


£ £ oc 


O 


-J 



a: 
o 
a 

UJ 

< 

Q 
Z 
UJ 
Q 

a 

< 
qq 

: S : . 



"> 


a: 

LU 
-1 CQ 

■VS1 

LU Z 
Q uj 
>- O 

a Z 

1- LU 
Z 3 

LU Of 
LU 

w 


2 


p 

£ 

■ d 
z 


h- 


06 
00 


-* 


DC 
UJ 
CO 

ii 

LU UJ 

82 

<3 

a 

LU 
CO 


. ■ 2' 




■ 'C 

E 

■ =■ 
z 


■* 


■ s 


«•» 


Q 
LU 

i 5 






•c 

0) 

E 
to 

■ -C 
Q. 
< 




as 


CO 
CO 

s 


CM 


18 

a uj 


2 


in 
p 


<N 


CO 

p 

CM 


> 


LU 

§8 

OO 

as 


2 


h- 


- 


9 















Q 

_l 

LU 

Ul 


DAM 

ELEMENT 

NAME 


Field 

Inclusion 

Requirement 


c 

.' c ■ 

■8- 


Cn 

g. 
-J 


' c 
.0 

& 



OR 66 



2005 OPERATING RULES 



APPENDIX TWO 



CD 








U 




^«* 




fl 




u; 




M 




U 




X 




u 


a 


& 


a 


W5 


o 


^ 
^ 


o 


© 


UJ 


W 
« 


a: 


tf 


j 


© 


< 


CU 


§>»>» 


W 


US 




Q 


S3 


£ 


c« 


■■■■■■'■■■ h- 


m 


z 


fs| 


UJ 


*"»( 


* 


<NI 


o 


& 


X 


o 




1— 1 




H 




U 




w 




CM 




« 




& 




W3 





CM 


ujg 

■:.M. 


5 


o 
E 


*> 


o 

CO 




SsS 




O 








go < 

Q O O 

ago 








O) 


*■ 


2 


0) 

■ E 

■ 3 

. . z 


. ■ ^ 


1^- 
















. >• . 












a: 












< 




o 








Z 




'c 








o< 




(D 




CO 


o 


o 

(0 

5 


o 


E 
ca 

■ j= 
a. 
< 


CM 






s * 




o 






o> 


s * K 


DC 


E 

(0 


to 


CO 




- « D 




< 




(O 




« -1 




O 








ffiSg 




(D 

E 
ai 




o 


00 


O Z Jr 


QC 


CO 






Q. O 




< 






r» 


s s 1 


2 


o 

to 
a 
< 


lO 


o 








■»■ 








H 




•o- 






« 


Z 

o 


2 


to 
to 


O 


CO 

o 

CO 




H 
















o 

5 




a 


in 


O 2 


DC 


E 


r- 


CM 
CO 




<3 




■h 








LL* 




< 








O 










** 


St 

Ul O 

S 5 


5 


o 

E 
z 


- 


CM 




-. 2. 












ng 












o£ 




5 






**> 


So 


5 


1 


CD 


4 
O 




2 .'. 












o 












F ... 




o 








o g 




■ . 'C 




CO 


N 


« o 


2 


E 


CM 


o 

CM 




z o 

'■■*■■■ 




z 




O 




1- 












Q 












QC UJ UJ 










*-. 


°5-S 
o >- o 

UJ H O 


5 


JO 


. ■,- 


o 










o 




OC 


























c 










K 


£ 










? 


c S 


CO 






Q 

-1 . 
Ui 

u. 


k- m as 

S H S 
q uj a: 


o g> 

all 

CSC 


1 


1 

o 


I 




OR 67 



'APPENDIX-TWO. 



2005 OPERATING RULES 




SECTION 2.2 Code Values 

Addenda Record Indicator 

Record Format Location : Entry Detail Record and 
Corporate Entry Detail Record 

No addenda record follows the entry 

1 One or more addenda records follow the entry 

Addenda Type Codes 

Record Format Location : Addenda Record 

01 Cross-Border Entries (CBR, PBR) (Addenda 
Record is used to provide foreign payment 
information) 

02 Point of Sale Entry (POS), Shared Network 
Transaction (SHR), or Machine Transfer Entry 
(MTE) (Addenda Record is used for terminal 
location description information) 

05 Addenda Record (Applies to ACK, ATX, CCD, 

CIE, CTX, DNE, ENR, PPD, TRX, and WEB 
Entries) 

98 Automated Notification of Change (COR) 
Addenda Record and Automated Refused 
Notification of Change (COR) Addenda Record 

99 Automated Return Entry Addenda Record, 
Automated Dishonored Return Entry Addenda 
Record and Automated Contested Dishonored 
Return Entry Addenda Record 



Card Transaction Type Codes 

Record Format Location : Entry Detail Record of POS 



and SHR Entries. 


01 


Purchase of goods or services 


02 


Cash 


03 


Return Reversal 


11 


Purchase Reversal 


12 


Cash Reversal 


13 


Return 


21 


Adjustment 


99 


Miscellaneous Transaction 



Item Type Indicator 

Record Format Location : Entry Detail Record for TRC 
and TRX Entries. 



01 



NACS Truncated Items 



Originator Status Codes 

Record Format Location : Company /Batch Header 
Record 

ADV file prepared by an ACH Operator. 

1 This code identifies the Originator as a 
depository financial institution which has agreed 
to be bound by these rules. 

2 This code identifies the Originator as a federal 
government entity or agency not subject to these 
rules. 



Record Type Codes 

Record Format Location : The first position of all record 
formats. These codes are uniquely assignedfor each type 
of record as follows: 



1 File Header Record Format 

5 Company/Batch Header Record Format 

6 Entry Detail Record Format (Consumer 
Corporate) 

7 Addenda Record Formats 

8 Company/Batch Control Record Format 

9 File Control Record Format 



Service Class Codes 



and 



Record Format Location : Company /Batch Header 
Record and Company /Batch Control Record 

200 ACH Entries Mixed Debits and Credits 

220 ACH Credits Only 

225 ACH Debits Only 

280 ACH Automated Accounting Advices 



Standard Entry Class Codes 

Record Format Location : Company/Batch Header 
Record 



ACK 

ADV 

ARC 

ATX 

CBR 

CCD 

CIE 

COR 



CTX 
DNE 
ENR 
MTE 
PBR 
POP 
POS 



ACH Payment Acknowledgment 

Automated Accounting Advice 

Accounts Receivable Entry 

Financial EDI Acknowledgment 

Corporate Cross-Border Payment 

Cash Concentration or^Disbursement 

Customer Initiated Entry 

Automated Notification of Change and 

Automated Refused Notification of Change 

Corporate Trade Exchange 

Death Notification Entry 

Automated Enrollment Entry 

Machine Transfer Entry 

Consumer Cross-Border Payment 

Point-of-Purchase Entry 

Point of Sale Entry 



OR68 



2005 OPERATING RULES 



APPENDIX TWO 



PPD Prearranged Payment and Deposit Entry 

RCK Re-presented Check Entry 

SHR Shared Network Transaction 

TEL Telephone-Initiated Entry 

TRC Truncated Entry 

TRX Truncated Entries Exchange 

WEB Internet-Initiated Entry 

XCK Destroyed Check Entry 



Transaction Codes 

Record Format Location: Entry Detail Record 

Demand Credit Records (for checking, NOW, and share 
draft accounts) 

20 Reserved 

21 Automated Return or Notification of Change for 
original transaction code 22, 23, or 24 

22 Automated Deposit 

23 Prenotification of Demand Credit Authorization; 
Death Notification (non-dollar); Automated 
Enrollment Entry (non-dollar) 

24 Zero dollar with remittance data (for CCD and 
CTX entries only); Acknowledgment Entries 
(ACK and ATX entries only) 

Demand Debit Records (for checking, NO W y and share 
draft accounts) 

25 Reserved 

26 Automated Return or Notification of Change for 
original transaction code 27, 28, or 29 

27 Automated Payment 

28 Prenotification of Demand Debit Authorization 
(non-dollar) 

29 Zero dollar with remittance data (for CCD and 
CTX entries only) 

Savings Account Credit Records 



Savings Account Debit Records 



30 
31 

32 

33 



34 



Reserved 

Automated Return or Notification of Change for 

original transaction code 32, 33, or 34 

Automated Deposit 

Prenotification of Savings Credit Authorization; 

Death Notification (non-dollar); Automated 

Enrollment Entry (non-dollar) 

Zero dollar with remittance data (for CCD and 

CTX entries only); Acknowledgment Entries 

(ACK and ATX entries only) 



35 
36 

37 
38 

39 



Reserved 

Automated Return or Notification of Change for 

original transaction code 37, 38, or 39 

Automated Payment 

Prenotification of Savings Debit Authorization 

(non-dollar) 

Zero dollar with remittance data (for CCD and 

CTX entries only) 



Financial Institution General Ledger Credit Records 

41 Automated Return or Notification of Change for 
original transaction code 42, 43, or 44 

42 Automated General Ledger Deposit (Credit) 

43 Prenotification of General Ledger Credit 
Authorization (non-dollar) 

44 Zero dollar with remittance data (for CCD and 
CTX entries only) 

Financial Institution General Ledger Debit Records 




46 

47 
48 

49 



Automated Return or Notification of Change for 
original transaction code 47, 48, or 49 
Automated General Ledger Payment (Debit) 
Prenotification of General Ledger Debit 
Authorization (non-dollar) 
Zero dollar with remittance data (for CCD and 
CTX only) 



Loan Account Credit Records 

51 Automated Return or Notification of Change for 
original transaction code 52, 53, or 54 

52 Automated Loan Account Deposit (Credit) 

53 Prenotification of Loan Account Credit 
Authorization (non-dollar) 

54 Zero dollar with remittance data (for CCD and 
CTX entries only) 



Loan Account Debit Records (for Reversals Only) 

55 
56 



Automated Loan Account Debit (Reversals 

Only) 

Automated Return or Notification of Change for 

original transaction code 55 



Automated Accounting Records (for use in ADV files 
only) 

These transaction codes represent accounting entries and 
not actual ACH transactions. 



81 Credit for ACH debits originated 

82 Debit for ACH credits originated 

83 Credit for ACH credits received 

84 Debit for ACH debits received 

85 Credit for ACH credits in rejected batches 

86 Debit for ACH debits in rejected batches 
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87 Summary credit for respondent ACH activity 

88 Summary debit for respondent ACH activity 



SECTION 2.3 Glossary of File Format Data Elements 

Field Inclusion Requirements 

The following information defines the need for inclusion 
of certain data fields in ACH entries/This involves the 
standardization of three definitions: Mandatory, 
Required, and Optional. 

Mandatory/or ACH Processing. A "Mandatory" field is 
necessary to ensure the proper routing and/or posting of 
an ACH entry. Any "Mandatory" field not included in an 
ACH record will cause that entry, batch, or file to be 
rejected by the ACH Operator. A rejected entry will be 
returned to the ODFI by the ACH Operator. A rejected 
batch or rejected file will be reported to the ODFI or 
Sending Point by the ACH Operator. 

Required. The omission of a "Required" field will not 
cause an entry reject at the ACH Operator, but may cause 
a reject at the RDFI. An example is the DFI Account 
Number field in the Entry Detail Record. If this field is 
omitted by an ODFI, the RDFI may return the entry as 
nonpostable. Data classified as "Required" should be 
included by the Originator and ODFI to avoid processing 
and control problems at the RDFI. 

Optional. The inclusion or omission of an "Optional" 
data field is at the discretion of the Originator and ODFL 
However, if a DFI does originate files using optional data 
fields, these fields must be returned to the ODFI if the 
entry is returned. 



Glossary of Data Elements 

ACH Operator Data ( AD V) : 1 9 Positions - Company/ 
Batch Control Record - Optional; 1 Position - Entry Detail 
Record -, Optional 

This field is used as specified by the ACH Operator. 



Addenda Information (returns): 44 Positions - Addenda 
Record - Optional (except CBR and PBR); 8 positions - 
Addenda Record - Optional (CBR, PBR) 

Addenda Information is associated with the immediately 
preceding Entry Detail Record. 

The Addenda Information field of a Return Entry is used 
by the RDFI to relay explanatory information that is 
required with the use of Return Reason Codes "Rll" 
(Check Truncation Return) and "R17" (File Record Edit 
Criteria), and to return any information contained in an 
Addenda Record accompanying the original entry. Return 
entries that have been automated by the RDFI or 



converted to automated returns by the ACH Operator will 
retain the Standard Entry Class Code of the original entry 
(i.e., CCD, CIE, COR, CTX, ENR, MTE, POS, SHR, 
PPD, or WEB), and therefore must be identified by the 
transaction code and the Addenda Type Code "99". 



Addenda Record Indicator (ACK, ADV, ARC, ATX, 
CBR, CCD, CIE, CTX, DNE, ENR, MTE, PBR, POP, 
POS, PPD, RCK, SHR, TEL, TRC, TRX, WEB, XCK, 
refused ACK, refused ATX, returns, dishonored returns, 
contested dishonored returns, COR, refused COR): 1 
Position - Entry Detail Record and Corporate Entry Detail 
Record - Mandatory 

This field indicates the existence of an Addenda Record. 
A value of " 1 " indicates that one or more addenda records 
follow, and "0" means no such record is present. (See 
currently assigned "Code Values" in this Appendix Two.) 



ACK, ATX, CCD, CIE, and CTX, refused ACK, refused 

ATX: This field indicates the existence of Addenda 
Record(s) following this Corporate Entry Detail Record 
or Entry Detail Record. A value of "0" means that no 
such record is present. A value of " i " means one or more 
Addenda Record(s) is following. 

Zero Dollar, Automated Notification of Change, 
Automated Refused Notification of Change, Return, 
Automated Dishonored Return, Automated Contested 
Dishonored Return, DNE, ENR, MTE, POS, SHR, and 
TRX entries: The value of this field will always be " 1 " . 
This is not applicable to MTE, POS, SHR, or TRX 
prenotifications. 



Addenda Sequence Number (ACK, ATX, CCD, CIE, 

CTX, DNE, ENR, PPD, TRX, WEB): 4 Positions - 
Addenda Record - Mandatory 

This number is consecutively assigned to each Addenda 
Record following an Entry Detail Record. The first 
addenda sequence number must always be a "1 ." 



Addenda Type Code (ACK: ATX: CBR, CCD, CIE, 
CTX, DNE, ENR, MTE, PBR, POS, PPD, SHR, TRX, 

WEB, returns, dishonored returns, contested dishonored 
returns, COR, refused COR): 2 Positions - Addenda 
Record - Mandatory 

The Addenda Type Code defines the specific 
interpretation and format for the Addenda Information 
contained in the same record. See list of Addenda Type 
Codes under currently assigned "Code Values" in this 
Appendix Two. 
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Advice Routing Number (ADV): 9 Positions - Entry 
Detail Record - Mandatory 

This field contains the Routing Number and Check Digit 
of the DFI or Respondent or Correspondent as defined by 
the ACH Operator. 



Block Count (all Standard Entry Class Codes): 6 
Positions - File Control Record - Mandatory 

The Block Count contains the number of physical blocks 
(a block is 940 characters) in the file, including both the 
File Header and File Control Records. 



Amount (ACK, ADV, ARC, CBR, CCD, CIE, DNE, 
ENR, MTE, PBR, POP, POS, PPD, RCK, SHR, TEL, 
TRC, WEB, XCK, refused ACK, returns, dishonored 
returns, contested dishonored returns, COR, refused 
COR): 10 Positions - Entry Detail Record - Mandatory; 
12 Positions - ADV Entry Detail Record - Mandatory 

The RDFI posts the amount to the appropriate account 
authorized by the Receiver. A zero Amount is acceptable 
only with specific Transaction Codes. 

ADV: The Automated Accounting Advice contains a 12 
position field to record the summary debit or credit 
amount. An additional 2 characters for the Amount field 
is obtained by truncating the DFI Account Number field 
to 15 characters. 

ACK, DNE, ENR: The value of this field is always zero. 

CBR, PBR: The value of this field is always reflected in 
U.S.Dollars. 



Blocking Factor (all Standard Entry Class Codes): 2 
Positions - File Header Record - Mandatory 



The Blocking Factor defines the number of physical 
records within a block (a block is 940 characters). For all 
files moving between a DFI and an ACH Operator (either 
way), the value "10" must be used. If the number of 
records within the file is not a multiple of ten, the 
remainder of the block must be nine filled. 



Card Expiration Date (POS, SHR): 4 Positions - Entry 
Detail Record - Required; 6 Positions - Addenda Record - 
Optional 

POS, SHR: This code is used by cardholder processors 
and cardholder Fmancial Institutions to verify that the 
card remains valid and that certain security procedures 
required by various card authorization systems have been 
met. 




Authorization Code (POS. SHR): 6 Positions - Addenda 
Record - Optional 

POS, SHR: This field indicates the code which a card 
authorization center has furnished to the merchant. 

The code is the Originator's record of having obtained 
such authorization. (NOTE: The field is left justified and 
blank filled.) 



Batch Count (all Standard Entry Class Codes): 6 
Positions - File Control Record - Mandatory 

The value of this field must be equal to the number of 
Company/Batch Header Records in the file. 



Card Transaction Type Code (POS, SHR): 2 Positions - 
Entry Detail Record - Mandatory 

POS, SHR: This code is used by card processors to 
identify the type of transactions, such as purchases, cash 
advances and reversals. Values in this field are predicated 
upon values assigned by the major card organizations. 



Change Code (COR, refused COR): 
Addenda Record - Mandatory 



3 Positions 



A standard symbol used by the RDFI to describe the 
reason for sending a notification of change to inform the 
ODFI that information has become outdated or that 
information contained on a prenotification should be 
corrected. 



Batch Number (all Standard Entry Class Codes): 7 
Positions - Company/Batch Header Record and 
Company/Batch Control Record - Mandatory 

This number is assigned in ascending sequence to each 
batch by the ODFI or its Sending Point in a given file of 
entries. Since the batch number in the Company/Batch 
Header Record and the Company/Batch Control Record 
is the same, the ascending sequence number should be 
assigned by batch and not by record. 



Check Disk (ACK, ADV, ARC, ATX, CBR, CCD, CIE, 
CTX, DNE, ENR, MTE, PBR, POP, POS, PPD, RCK, 
SHR, TEL, TRC, TRX, WEB, XCK, refused ACK, 
refused ATX, returns, dishonored returns, contested 
dishonored returns, COR, refused COR): Subfield Within 
Individual DFI Identification - Mandatory 

The Check Digit is computed using Modulus 1 as 
follows: 



OR 71 



APPENDIX TWO 



2005 OPERA TING RULES 



(1) 



Multiply each digit in the Routing Number by a 
weighting factor. The weighting factors for each 
digit are: 



Position: 
Weights: 



12345 67 8 

37 137 137 



(2) 
(3) 




Add the results of the eight multiplications. 

Subtract the sum from the next highest multiple 
of 10. The result is the Check Digit. 

Example: 



Routing No.: 7 6 4 1 2 5 
Multrolvbv: 3 7 1 3 7 13 7 

Sum: 49 6 12 1 6 35 =109 



CheckDigit= 1 (110 minus 109) 



Check Serial Number . 1 5 Positions - Entry Detail Record 
- Optional (TRC, returns, dishonored returns, contested 
dishonored returns): 15 Positions - Entry Detail Record - 
Mandatory (ARC, RCK, XCK); 9 Positions - Entry Detail 
Record - Mandatory (POP) 

This field contains the serial number of a check. 

ARC, POP: This field must contain the Check Serial 
Number contained on the source document used for the 
entry. 



Company Descriptive Date (ACK, ADV, ARC, ATX, 
CCD, CIE, CTX, DNE, ENR, MTE, POP, POS, PPD, 
RCK, SHR, TEL, TRC, TRX, WEB, XCK, returns, 
dishonored returns, contested dishonored returns, COR, 
refused COR): 6 Positions - Company/Batch Header 
Record -Optional 

Except as otherwise noted below, the Originator 
establishes this field as the date it would like to see 
displayed to the Receiver for descriptive purposes. This 
field is never used to control timing of any computer or 
manual operation. It is solely for descriptive purposes. 
The RDFI should not assume any specific format. 
Examples of possible entries in this field are "01 1392," 
"01 92," "JAN 13," "JAN 92," etc. 



MTE, POS, and SHR: This date is the actual date the 
transfer was initiated by the Receiver, and formatted the 
same as the effective entry date (YYMMDD). 



TRC: This field contains the film date established by the 
Keeper (ODFI) for checks being truncated. 



Company Discretionary Data (ACK, ADV, ARC, ATX, 
CCD, CIE, CTX, DNE, ENR, MTE, POP, POS, PPD, 
RCK, SHR, TEL, TRC, TRX, WEB, XCK, returns, 
dishonored returns, contested dishonored returns, COR, 
refused COR): 20 Positions - Company/Batch Header 
Record- Optional 

This field in the Company/Batch Header Record allows 
Originators and/or ODFIs to include codes (one or more), 
of significance only to them, to enable specialized 
handling of all subsequent entries in that batch. There 
will be no standardized interpretation for the value of the 
field. This field must be returned intact on any return 
entry. 

CIE: This field contains the Biller's name. 

CTX: The Originator's bank account number may be 
placed in this field. This field is left justified. 



POS: The Originator (card acquirer) may place document 
reference numbers or other codes significant to it. The 
field is left justified. 

TRC: This field contains the city, state, and zip code of 
the keeper. 



Company Entry Description (all Standard Entry Class 
Codes): 10 Positions - Company/Batch Header Record - 
Mandatory 

The Originator establishes the value of this field to 
provide a description of the purpose of the entry to be 
displayed back to the Receiver. For example, "GAS 
BILL," "REG. SALARY," "INS.PREM," "SOC. SEC," 
"DTC," "TRADE PAY," "PURCHASE," etc. 

This field must contain the word "REVERSAL" (left 
justified) when the batch contains reversing entries. 



This field must contain the word "RECLAIM" (left 
justified) when the batch contains reclamation entries. 

This field must contain the word "NONSETTLED" (left 
justified) when the batch contains entries which could not 
settle. 

ADV: The company, i.e., the originating ACH Operator, 
uses this field to describe to the institution receiving the 
ADV file the type of activity to which the accounting 
information relates. 

ENR: This field must contain the word 
"AUTOENROLL" (left justified) when the batch contains 
automated enrollment entries. 

RCK: This field must contain the word "REDEPCHECK" 
(left justified). 
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TEX: This field contains the routing number of the 
keeper. 

XCK: This field must contain the words "NO CHECK" 
(left justified). 



Company Identification (all Standard Entry Class 
Codes): 10 Positions - Company/Batch Header Record- 
Mandatory; Company/Batch Control Record - Required 

The Company Identification is an alphameric code used 
to identify an Originator. The Company Identification 
Field must be included on all prenotification records and 
on each entry initiated pursuant to such prenotification. 

The Company ID may begin with the ANSI one-digit 
Identification Code Designators (ICD), followed by the 
identification number. The ANSI Identification Numbers 
and related Identification Code Designators (ICD) are: 



IRS Employer Identification Number (EIN) " 1 "'■ 
Data Universal Numbering Systems (DUNS) "S" 
User Assigned Number "9" 

CIE: This field contains the Bill Payment Service 
Provider's identification number. 

MTE (Credits): The company is the ODFL 



Company Name (all Standard Entry Class Codes): 16 
Positions - Company/Batch Header Record - Mandatory 

Except as otherwise noted below, the value of this field is 
established by the Originator for purposes of further 
identifying the source of the entry and for descriptive 
purposes for the Receiver. 

ADV: An ACH Operator is both the company and the 
ODFL The ACH Operator originating the ADV file 
identifies himself by name in this field. 

ARC: This field must contain the name of the Originator, 
which is the original payee on the face of the source 
document. 



CIE: This field contains the Bill Payment Service 
Provider's name. 

MTE: The value of this field is established by the ODFL 
It is used for descriptive purposes and should identify the 
ODFI for credits and the payee Company for debits. 

POP: This field must contain the name of the merchant 
(payee). 

RCK: This field identifies the Originator of the RCK 
entry, which is the original payee on the face of the check. 



SHE: This field identifies the merchant with whom the 
Receiver initiated the transactions. 

TEC: This field identifies the name of the keeper. 

XCK: This field must contain the words "CHECK 
DESTROYED" (left justified). 



Contested Dishonored Return Eeason Code (contested 
dishonored returns): 3 Positions - Addenda Record - 
Mandatory 

A standard code used by the RDFI of a Dishonored 
Return to describe the reason for contesting a Dishonored 
Return. 



Corrected Data (COR, refused COR): 29 Positions - 
Addenda Record - Mandatory 

The corrected data field is used by the RDFI to relay 
corrected customer information (i.e., DFI Account 
Number, Transaction Code, etc.) back to the Originator of 
that entry. The corrected data field in an Automated 
Refused Notification of Change is copied from the 
corrected data field of the original Notification of Change. 



COE Trace Sequence Number (refused COR): 7 
positions - Addenda Record - Mandatory 

The last seven digits of the Trace Number contained in the 
original notification of change. This field should be left 
justified. 



Date of Death (returns): 6 Positions - Addenda Record - 
Optional 

The date of death is to be supplied on those entries being 
returned in the automated return item format for reason of 
death (return reason codes R14 and R15). 



Date Original Entry Returned (contested dishonored 
returns): 6 positions - Addenda Record - Mandatory with 
R73, otherwise Optional 

The date original entry returned is used when a 
Dishonored Return entry is contested on the grounds that 
the original return was untimely (R73). It is the date the 
RDFI initiated the original return. 



DFI Account Number (ACK, ADV, ARC, ATX, CBR, 
CCD, CIE, CTX, DNE, ENR, MTE, PBR, POP, POS, 
PPD, RCK, SHR, TEL, TRC, TRX, WEB, XCK, refused 
ACK, refused ATX, returns, dishonored returns, contested 
dishonored returns, COR, refused COR): 17 Positions - 
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Entry Detail Record -Required; 15 Positions 
Entry Detail Record - Required 



ADV 




The DFI Account Number, the RDFI's customer 
identification, is obtained from: (1) the "on-us" field of 
the MICR line of a voided check/share draft; (2) statement 
of account; (3) passbook; or (4) other source document 
provided by the RDFI which specifically designates the 
account number to be used for ACH purposes. A DFI that 
does not use the MICR line of its checks/share drafts for 
ACH routing purposes (routing number and account 
number) is advised to print clearly the correct routing 
information on the face of the check/share draft. 

When transcribing information from the on-us field of a 
voided check or deposit ticket, left justify the information 
and enter only numbers (0 through 9) and hyphens (-). If 
information is obtained from another source, alpha 
characters may be included. 

If the on-us field contains greater than 17 valid characters, 
the leftmost 1 7 characters are inserted in the DFI Account 
Number field and the remaining characters truncated, e.g., 
"01 234567 890 12345 67" will appear 
"01 2345 67890 123456" in the entry detail record. If fewer 
than 1 7 characters, left justify and leave the unused spaces 
blank. Spaces left within the Receiver account number 
should be ignored when the paperless entry is prepared, 
e.g., "0123 456789" should appear "0123456789" in the 
entry detail record; "0123-4 56789" should appear 
"0123-456789." Exact formatting of the DFI Account 
Number Field is essential to ensure standard positioning 
of account number characters when entries are received 
for processing at the RDFI. 

ADV. Contains a 15 character DFI Account Number. 
The 16th and 17th positions of the DFI Account Number 
are used to expand the Amount field to 12 positions. 

CBR, PBR- This field contains the Foreign Receiver's 
Account Number, or the leftmost 17 characters if the 
Foreign Receiver's Account Number exceeds 17 
characters. ( NOTE : The full Foreign Receiver's Account 
Number is always expressed in the Addenda Record.) 

ENR : Contains information provided by the Federal 
Government Agency participating in the Automated 
Enrollment program. 



can either be a single two-character code, or two distinct 
one-character codes, according to the needs of the ODFI 
and/or Originator involved. This field must be returned 
intact for any returned entry. 

CCD 9 CTX: When an acknowledgment entry is requested 
by an Originator, this field will contain "AK". 



Dishonored Return Reason Code (dishonored returns, 
contested dishonored returns): Addenda Record; 3 
Positions - Dishonored Return Entry - Mandatory; 2 
Positions ■'.-.- Contested Dishonored Return Entry - 
Mandatory 

A standard code used by the ODFI to describe the reason 
for dishonoring a Return Entry. In a Contested 
Dishonored Return Entry, only the numeric portion of the 
code is used. 



Dishonored Return Settlement Date (contested 
dishonored returns): 3 Positions - Addenda Record - 
Mandatory 

The Dishonored Return Settlement Date is used in the 
Automated Contested Dishonored Return format. Data 
for this field is obtained from the Settlement Date field of 
the Automated Dishonored Return Company/Batch 
Header Record. 



Dishonored Return Trace Number (contested dishonored 
returns): 15 Positions - Addenda Record - 
Mandatory 

The Dishonored Return Trace Number is used in the 
Automated Contested Dishonored Return format. The 
data for this field is obtained from positions 80 - 94 of the 
Addenda Record or positions 80 - 94 of the Entry Detail 
Record of the Automated Dishonored Return Entry. 



11 Positions 



Document Reference Number (SHR): 
Entry Detail Record - Required 



This field further defines the transaction in the event of a 
Receiver's inquiry. Examples are microfilm reference 
number or an electronic sequence number. 



Discretionary Data (ACK, ADV, ARC, ATX, CBR, 
CCD, CIE, CTX, DNE, MTE, PBR, POP, PPD, RCK, 
TEL, XCK, returns, dishonored returns, contested 
dishonored returns, COR, refused COR): 2 Positions - 
Entry Detail Record, Corporate Entry Detail Record - 
Optional 

This field in the Entry Detail Record allows ODFIs to 
include codes, of significance only to them, to enable 
specialized handling of the entry. There will be no 
standardized interpretation for the value of this field. It 



Effective Entry Date (all Standard Entry Class Codes): 
6 Positions - Company/Batch Header Record - Required 

The effective entry date is the date specified by the 
Originator on which it intends a batch of entries to be 
settled. For credit entries, the effective entry date shall be 
either one or two banking days following the banking day 
of processing as established by the Originating ACH 
Operator (the processing date). For debit entries, the 
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effective entry date shall be one banking day following the 
processing date. 

Batches of entries containing an effective entry date 
beyond the designated number of days allowed will be 
rejected by the ACH Operator and returned to the ODFL 
If this field is blank or zero, or partially blank or partially 
non-numeric, or contains an incomplete date, day numbers 
higher than 3 1 or month numbers higher than 12, the 
Originating ACH Operator shall insert the next banking 
day after the processing date as the effective entry date. 

ENR: For Automated Enrollment entries, this field should 
be space filled. 

Return Entries, COR,TRC, TRX: The ACH Operator 
will not edit this field. 

The scheduled Settlement Date shall be inserted by the 
Receiving ACH Operator. See the definition of 
"Settlement Date" in this Appendix Two* 

For purposes of mis provision, me term "banking day" 
refers to a day on which the Originating ACH Operator's 
facility is being operated. 

Entry/Addenda Count (all Standard Entry Class Codes): 
6 Positions - Company/Batch Control Record -Mandatory; 
8 Positions - File Control Record - 
Mandatory 

This count is a tally of each Entry Detail Record and each 
Addenda Record processed, within either the batch or file, 
as appropriate. 



digit routing number of the receiving depository 
institution. The hash is the arithmetic sum of the 8-digit 
routing numbers, with overflow out of the high order 
(leftmost) position ignored. 



File Control Record: 

corresponding fields 
Records on the file. 



in 



The Entry Hash is the sum of 
the Company/Batch Control 



File Creation Date (all Standard Entry Class Codes): 6 
positions - File Header Record - Mandatory 

The File Creation Date is expressed in a "YYMMDD" 
format. The File Creation Date is the date on which the 
file is prepared by an ODFI (ACH input files) or the date 
(exchange date) on which a file is transmitted from ACH 
Operator to ACH Operator, or from ACH Operator to 
RDFIs (ACH output files). 



File Creation Time (all Standard Entry Class Codes): 4 
positions -File Header Record - Optional 

The File Creation Time is expressed in an "HHMM" (24 
hour clock) format. 




File Identification (ADV): 

Record - Optional 



5 Positions - Entry Detail 



This field contains the File Creation Date and File ID 
Modifier associated with the Automated Accounting 
Advice entry. 



Entry Detail Sequence Number (ACK. ATX, CCD, CIE, 
CTX, DNE, ENR, PPD, TRX, WEB,): 7 Positions - 
Addenda Record - Mandatory 

This field contains the ascending sequence number section 
of the Entry Detail or Corporate Entry Detail Record's 
trace number. This number is the same as the last seven 
digits of the trace number (Field 13) of the related Entry 
Detail Record or Corporate Entry Detail Record. 



Entry Hash (all Standard Entry Class Codes): 10 
Positions - Company/Batch Control Record and File 
Control Record - Mandatory 

the Receiving DFI Identification in each Entry Detail 
Record is hashed to provide a check against inadvertent 
alteration of data contents due to hardware failure or 
program error. (NOTE: Addenda Records are not 
hashed.) 

Company/Batch Control Record: The Entry Hash is the 
sum of the Receiving DFI Identification fields in Entry 
Detail Records in the batch. This field contains the 8- 



File ID Modifier (all Standard Entry Class Codes): 1 
Position - File Header Record - Mandatory 

The File ID Modifier is provided in the File Header 
Record to permit multiple files created on the same date 
and between the same participants to be distinguished. 
Only upper case A-Z and numeric 0-9 are permitted. 

ADV: The number in this field reflects, in chronological 
order, the number of advices given in a particular cycle. 
The highest numbered advice is the last advice of the 
cycle. 



Foreign Exchange Indicator (CBR; PBR, returns 
dishonored returns, contested dishonored returns, COR, 
refused COR): 2 Positions - Company/Batch Header 
Record - Required 

Code used to indicate the foreign exchange conversion 
methodology applied to a cross-border entry. Use may be 
dependent on the particular exchange services offered by 
a Gateway Operator. Code values for this field are; 
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"FV" Fixed-to-Variable - Entry is originated in a 
fixed-value amount and is to be received in a 
variable amount resulting from the execution of 
the foreign exchange conversion. 

"VF" Variable-to-Fixed -. Entry is originated in a 
variable-value amount based on a specific 
foreign exchange rate for conversion to a fixed- 
value amount in which the entry is to be 
received. 

"FF" Fixed-to-Fixed -' Entry is originated in a fixed- 
value amount and is to be received in the same 
fixed-value amount in the same currency 
denomination. There is no foreign exchange 
conversion for entries transmitted using this 
code. For entries originated in a fixed-value 
amount, the Foreign Exchange Reference Field 
will be spacefilled. 



Foreign Exchange Reference (CBR, PBR, returns, 
dishonored returns, contested dishonored returns, COR, 
refused COR): 15 Positions - Company/Batch Header 
Record -Required 

Contains either the foreign exchange rate used to execute 
the foreign exchange conversion of a cross-border entry 
or another reference to the foreign exchange transaction. 
Content is defined by the Foreign Exchange Reference 
Indicator Field. 

If the Foreign Exchange Indicator Field contains "FF", 
this field will always be space filled. 



Foreign Exchange Reference Indicator (CBR, PBR, 
returns, dishonored returns, contested dishonored returns, 
COR, refused COR): 1 Position - Company/Batch Header 
Record - Required 

Code used to indicate the content of the Foreign Exchange 
Reference Field. Code values for this field are: 

1 - Foreign Exchange Rate; 

2 - Foreign Exchange Reference Number; or 

3 - Space Filled. 



Foreign Payment Amount (CBR, PBR, returns): 15 
Positions - Addenda Record - Required 

For inbound cross-border entries, this field contains the 
amount for which the entry was originated by the Foreign 
ODFI in the currency denomination expressed in the 
Originating Currency Code Field of the Company/Batch 
Header Record. For outbound entries originated using a 
Foreign Exchange Indicator of "FV" (fixed-to- variable), 
this field is zero-filled. 



For outbound entries using a Foreign Exchange Indicator 
of "VF" (variable-to-fixed) or "FF" (fixed-to-fixed), this 
field contains the amount for which the entry is to be 
received by the Foreign Receiver in the currency 
denomination expressed in the Destination Currency Code 
Field of the Company/Batch Header Record. 

For inbound entries returned by a U.S. RDFI, this field is 
copied from the original Entry Detail Record to the Entry 
Detail Record for cross-border returns. For outbound 
entries returned by a U.S. Originating Gateway Operator, 
this field contains the entry amount returned to the 
original ODFI. This amount will be different from the 
amount for which the original entry was originated if the 
same rate was not used for both the forward and return 
entry foreign exchange conversions. 



Foreign Receiving DFI Identification (CBR, PBR, 
returns): 1 1 Positions - Addenda Record - Required 

Contains a reference used to identify the foreign RDFI of 
a cross-border entry. For inbound cross-border entries, 
this field will contain the U.S. RDFI's routing number. 



Foreign Receiver's Account Number (CBR, PBR): 25 

Positions - Addenda Record - Required 

For outbound cross-border entries, this field contains the 
full account number of the account held by the Foreign 
Receiver. If the Foreign Receiver's account number is 
less than 18 characters, mis field contains the identical 
data contained in the DFI Account Number Field of the 
Entry Detail Record. For inbound cross-border entries, 
this field contains the U.S. Receiver's account number as 
provided in the DFI Account Number Field of the Entry 
Detail Record. 



Foreign Trace Number (CBR, PBR): 22 Positions - 
Addenda Record -Optional 

For inbound cross-border entries, this field contains the 
trace number assigned to the entry in the originating 
national payments system. 



Format Code (all Standard Entry Class Codes): 1 
Position - File Header Record - Mandatory 

This field identifies a code to allow for future format 
variations. 

As currently defined, this field will contain a value of M l. n 
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Identification Number (CBR, CCD, CTX, ENR, TRX, 
returns, dishonored returns, contested dishonored returns, 
COR, refused COR): 1 Positions - Entry Detail Record - 
Optional; 15 Positions - Corporate Entry Detail Record - 
Optional 



This field may be used by the Originator to insert its own 
number for tracing purposes. 

ENR: For Federal Government automated enrollment 
entries, this field should be space filled. 



Immediate Destination (all Standard Entry Class Codes): 

1 Positions - File Header Record - 

Mandatory 

This field contains the Routing Number of the ACH 
Operator or receiving point to which the file is being sent. 
The 10 character field begins with a blank in the first 
position, followed by the four digit Federal Reserve 
Routing Symbol, the four digit ABA Institution Identifier, 
and the Check Digit (bTTTTAAAAC). 



Immediate Destination Name (all Standard Entry Class 
Codes): 23 Positions - File Header Record - Optional 

This field contains the name of the ACH or receiving 
point for which that file is destined. 



Immediate Origin (all Standard Entry Class Codes): 10 
Positions - File Header Record - Mandatory 

This field contains the Routing Number of the ACH 
Operator or sending point that is sending the file. The 10 
character field begins with a blank in the first position, 
followed by the four digit Federal Reserve Routing 
Symbol, the four digit ABA Institution Identifier, and the 
Check Digit (bTTTTAAAAC). 

NOTE: This field may also be mutually defined between 
the ODFI and Originator. For example, the ODFI may 
ask its Originator to put its tax identification number in 
this field; however, the field must contain the routing 
number of the sending point when the file is delivered to 
me ACH Operator. 



Immediate Origin Name (all Standard Entry Class 
Codes): 23 Positions - File Header Record - Optional 

This field contains the name of the ACH Operator or 
sending point that is sending the file. 



Individual Card Account Number (SHR): 22 Positions - 
Entry Detail Record - Required 

The Individual Card Account Number is the number 
assigned by the card issuer and is obtained from the card 
. itself.----' 



Individual Identification Number (CIE, DNE, MTE, 
PBR, POS, PPD, TEL, WEB, returns, dishonored returns, 
contested dishonored returns, COR, refused COR): 15 
Positions - Entry Detail Record - Optional) 

Except as otherwise noted below, this field contains the 
accounting number by which the Receiver is known to the 
Originator. It is included for further identification and for 
descriptive purposes. The RDFI should assume no 
specific format to be present (e.g., presence or absence of 
dashes), but can assume that the field is pre-edited so that 
it is suitable for description as is (including blanks in 
unused positions). 

CIE: 22 Positions - Mandatory - This field contains the 
accounting number by which the Originator (payor) is 
known to the Receiver (payee). It will be used by the 
Receiver to update accounts receivable records. It should 
be the number shown on an invoice, statement, billhead, 
notice or other communication as the reference. Numbers 
may be policy, customer, invoice, meter, sequence and/or 
alphanumeric combinations. Field 8, rather than Field 7, 
of the Entry Detail Record is used for the Individual 
Identification Number. 

MTE: 22 Positions - Mandatory - Field 8, rather than 
Field 7, of the Entry Detail Record is used for the 
Individual Identification Number. 



Individual Name (ADV, CIE, DNE, MTE, PBR, POS, 
PPD, RCK, TEL, WEB, returns, dishonored returns, 
contested dishonored returns, COR, refused COR): 22 
Positions - Entry Detail Record - Required; 22 Positions - 
Entry Detail Record - Optional (ARC, POP) 

Except as noted below, this field entered by the Originator 
provides additional identification for the Receiver and 
may be helpful in identifying returned entries. 




ADV: Name associated with the Advice Routing Number 
in positions 40-48 of the Entry Detail Record. 

ARC, POP: This field may contain the Receiver's name 
or a reference number, identification number, or code that 
the merchant needs to identify the particular transaction or 
customer. 

CIE: 15 Positions - Required - This field entered by the 
ODFI provides additional identification for the Receiver 
and may be helpful in identifying returned entries. Field 
7, rather than Field 8, of the Entry Detail Record is used 
for the Individual Name. 
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MTE: 15 Positions - Mandatory > Field 7 , rather than 
Field 8, of the Entry Detail Record is used for the 
Individual Name. 



ISO Destination Country Code (CBR, PBR, returns, 
dishonored returns, contested dishonored returns, COR, 
refused COR): 2 Positions - Company/Batch Header 
Record -Required " 

This field contains the two-character code as approved by 
the International Organization for Standardization (ISO) 
used to identify the country in which the entry is to be 
received. 



ISO Destination Currency Code (CBR, PBR, returns, 
dishonored returns, contested dishonored returns, COR, 
refused COR): 3 Positions - Company/Batch Header 
Record - Required 

This field contains the three-character code as approved 
by the International Organization for Standardization 
(ISO) used to identify the currency denomination in which 
the entry is to be received. 



ISO Originating Currency Code (CBR, PBR, returns, 
dishonored returns, contested dishonored returns, COR, 
refused COR): 3 Positions - Company/Batch Header 
Record - Required 



This field contains the three-character code as approved 
by the International Organization for Standardization 
(ISO) used to identify the currency denomination in which 
the entry was first originated. 



Item Research Number (TRC, XCK): 16 Positions - 
Entry Detail Record - Required 

This field contains the MICR locator number for check 
item research. 



Message Authentication Code (MAC) (all Standard Entry 
Class Codes): 19 Positions - Company/Batch Control 
Record - Optional 

The MAC is an eight character code derived from a 
special key used in conjunction with the DES algorithm. 
The purpose of the MAC is to validate the authenticity of 
ACH entries. The DES algorithm and key message 
standards must be in accordance with standards adopted 
by the American National Standards Institute. The 
remaining eleven characters of this field are blank. 



Network Identification Code (MTE): 
Addenda Record - Optional 



3 Positions 



This field uniquely identifies the various ATM networks 
and allows for processing of MTE transactions between 
DFIs belonging to different networks. 



Number of Items Paid (returns, dishonored returns, 
contested dishonored returns, COR, refused COR): 4 
Positions - Corporate Entry Detail Record - Mandatory 

This number represents the number of items in the batch 
being paid to the same business. This field will be zero 
filled if Field 12 (Addenda Record Indicator Value) on 
the Corporate Entry Detail Record is equal to "0." 



Number of Addenda Records (ATX, CTX, ENR, TRX, 
refused ATX): 4 Positions - Corporate Entry Detail 
Record/Entry Detail Record - Mandatory 

CTX: This number represents the number of addenda 
records associated with the Corporate Entry Detail 
Record. This field will be zero filled if Field 12 
(Addenda Record Indicator Value) of the related 
Corporate Entry Detail Record is equal to "0.". 

ATX f ENR 9 TRX: This number represents the number of 
addenda associated with the Entry Detail Record. 



Item Type Indicator (TRC, TRX): 2 Positions - Entry 
Detail Record - Optional 

This field indicates the type of items being truncated. 



Julian Date on Which Adyice is Created (ADV): 3 
positions - Entry Detail Record - Mandatory 

This field contains the Julian date on which an Automated 
Accounting Advice is created. 



OGO Identification (CBR, PBR, returns, dishonored 
returns, contested dishonored returns, COR, refused 
COR): 8 Positions - Entry Detail Record - Mandatory 

For outbound cross-border entries, this field contains the 
routing number of the Originating Gateway Operator. 



Original Entry Trace Number (returns, dishonored 
returns, contested dishonored returns, COR, refused COR, 
ACK, refused ACK, ATX, refused ATX): 15 Positions - 
Corporate Entry Detail Record, Entry Detail Record, 
Addenda Record - Mandatory 

The Trace Number as originally included on the entry 
being returned or acknowledged, or on the prenotification 
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the RDFI is rejecting, correcting, or for which a copy of 
the authorization is being requested. This field must be 
included as data in the Addenda Record for entries being 
returned to an ODFI. 



Original Forward Entry Payment Amount (returns): 10 
Positions - Addenda Record - Required 

This field contains the Amount for which a return entry 
was first originated. Outbound entries originated by a 
U.S. ODFI might be returned by the Originating Gateway 
Operator for a U. S, dollar value that differs from the 
original Amount due to foreign exchange conversion. The 
handling of foreign exchange is dictated by the 
ODFI/OGO agreement. In such cases when a different 
rate is used for the forward and return foreign exchange 
conversion execution, the value contained in this field will 
not equal the value conveyed in the Amount Field of the 
Entry Detail Record for Returns, which reflects the value 
of the funds actually returned. 



Original Receiving DFI Identification (returns, 
dishonored returns, contested dishonored returns, COR, 
refused COR): 8 Positions - Addenda Record - Required 



The Receiving DFI identification as originally included on 
the entry being returned or on the prenotification the 
RDFI is rejecting or correcting. This field should be 
included as data in the Addenda Record for entries being 
returned to an ODFI. 



Origin al Settlem entDate (contested dishonored returns): 
3 Positions - Addenda Record - Mandatory with R73, 
otherwise Optional 

The original Settlement Date is used when a Dishonored 
Return entry is contested on the grounds that the original 
return was untimely (R73). It is the Settlement Date of 
the original entry. 



Originating DFI Identification (all Standard Entry Class 
Codes): 8 Positions - Company/Batch Header Record and 
Company/Batch Control Record - Mandatory 

The Routing Number is used to identify the DFI 
originating entries within a given batch. 



Originator Status Code (all Standard Entry Class Codes) : 
1 Position -Company/Batch Header Record -Mandatory 

This code refers to the ODFI initiating the entry. (See 
Originator Status Codes located under "Currently 
Assigned Values" in this Appendix Two.) 

ADV. This field will contain "0". 



Payment Related Information (ACK, ATX, CCD, CIE, 
CTX, DNE, ENR, PPD, TRX, WEB): 80 Positions - 
Addenda Record - Optional 

In the addenda records of ACK, ATX, CCD, CIE, ENR, 
PPD, and WEB entries, an asterisk ("*") will be the 
delimiter between the data elements, and the backslash 
("\") will be the terminator between the data segments. 

ACK, ATX: This field will contain the ANSI ASC X12 
REF (Reference) data segment. This REF segment may 
be used to convey the Identification Number contained 
within the original CCD or CTX entry, and/or other 
information of significance to the Originator. 

CCD, PPD, WEB: Addenda records will contain 
payment related ANSI ASC X 1 2 data segments or 
NACHA endorsed banking conventions (i.e., Tax 
Payment, Child Support, or Electronic Dealer Drafting). 

CIE: This field will contain payment related ANSI ASC 
X 1 2 data segments used to further identify the payment or 
transmit additional remittance information. 

For Example: 

Nl*BT*JohmOoe\N3*12MainStreet\N4*^ 

CTX: This section allows for the transmission of 
information formatted in accordance with the syntax of 
ANSIASCX12.5andX12.6, an ASCX12 transaction set 
containing a BPR or BPS data segment, or payment 
related UN/EDIFACT syntax. 

DNE: Addenda records will contain the following 
NACHA endorsed banking convention starting in position 
04: 

DATE OF DEATH*MMDDYY*CUSTOMERSSN* 

#########*AMOUNT*$$$$.cc\ 

The date of death will always appear in positions 18-23. 
If the Social Security Number (SSN) is not available, 
positions 38-46 will contain zeros. The amount of the 
expected beneficiary payment will always begin in 
position 55. 

ENR: This field will contain the following NACHA 
endorsed banking convention: 

All information in this field pertains to the account holder 
on whose behalf the Automated Enrollment entry is 
initiated. 

Transaction Code — This field will contain the 
Transaction Code of the account holder's account. This 
field should contain "22" (Automated Deposit for 
Demand Credit Account Records), "27" (Automated 
Payment for Demand Debit Account Records), "32" 
(Automated Deposit for Savings Account Credit Records), 
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or "37" (Automated Payment for Savings Account Debit 
Records). (2 positions) 

Receiving DFI Identification Number .— This field will 
contain the routing number used to identify the DFI at 
which the account holder maintains its account. (8 
positions) 

Check Digit — This field will contain the check digit 
pertaining to the routing number for the DFI at which the 
account holder maintains its account. (1 position) 

DFI Account Number - This field will contain the 
account holder's account number. (1 - 17 positions) 

Individual Identification Number/Identification Number-- 
For automated enrollments initiated on behalf of 
consumers, this field will contain the consumer's Social 
Security Number, For automated enrollments initiated on 
behalf of companies, this field will contain the company's 
Taxpayer Identification Number. (9 positions) 



Individual Name (Surname) /Company Name — This field 
will contain the consumer's surname or the first fifteen 
characters of the Company Name. (1 - 15 positions) 

Individual Name (First Name)/Company Name - This 
field will contain the consumer's first name or the next 
seven characters of the Company Name. (1-7 positions). 

Representative Payee Indicator/Enrollee Classification 
Code — For enrollments for Federal Government benefit 
payments, this field will contain "0" (zero) meaning "no" 
or "1" (one) meaning "yes" to denote whether the 
authorization is being initiated by someone other than the 
named beneficiary. 

For all other enrollments, this field will contain "A" to 
indicate that the enrollee is a consumer, or "B" to indicate 
that the enrollee is a company. (1 position) 



For Example: 

22*12200004*3*123987654321*777777777*DOE*JO 

HN*0\ 

22*12200004*3*987654321 123*876543210*ABCCO 
MPANY**B\ 

27*12200004*3*987654321 123*876543210*ABCELE 
CTRONICIN*DUSTRIE*B\ 

TEX: This section allows for the transmission of 
information formatted in accordance with National 
Association for Check Safekeeping syntax. 



Payment Type Code (WEB): 2 Positions - Entry Detail 
Record - Required 

This field is used to indicate whether a WEB entry is a 
recurring or Single-Entry payment. For a recurring WEB 
entry, this field must contain the value "R". For a Single- 
Entry WEB entry, this field must contain the value "S". 



Priority Code (all Standard Entry Class Codes): 2 
Positions - File Header Record - Required 

This field is included to allow for some future scheme for 
priority handling of files. At this time, a value of X QV 
should be used. 



Process Control Field (TRC, XCK): 6 Positions - Entry 
Detail Record -Required 

This field contains an optional code, as obtained from a 
check or sharedraft, which generally identifies the 
document type. The field is usually located to the right of 
the on-us account number on the MICR line and is 
sometimes called a transaction code. 



Receiving Company Name (ACK, CBR, CCD, refused 
ACK, returns, dishonored returns, contested dishonored 
returns, COR, refused COR): 22 Positions - Entry Detail 
Record - Required 

This field entered by the Originator provides additional 
identification for the Receiver and may be helpful in 
identifying return entries. 



Receiving Company Name/ID Number (ATX, CTX, 
ENR, TRX, refused ATX, returns, dishonored returns, 
contested dishonored returns, COR, refused COR): 1 6 
Positions - Corporate Entry Detail Record -Required 

This field identifies the Receiver and can be used for 
descriptive purposes. The field may contain the 
Receiving Company's name or an identifying number for 
that Company. The field should be left justified. 

ENR: This field should contain the name of the Federal 
Government Agency participating in the Automated 
Enrollment program. (Federal Government Agencies will 
provide this information to DFIs initiating Automated 
Enrollment entries.) 
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Receiving BFI Identification (ACK. ADV. ARC. ATX. 
GBR, CCD, CIE, CTX, DNE, ENR, MTE, PBR, POP, 
POS, PPD, RCK, SHR, TEL, TRC, TRX, WEB, XCK, 
refused ACK, refused ATX, returns, dishonored returns, 
contested dishonored returns, COR, refused COR): 8 
Positions - Entry Detail Record - Mandatory 

The standard Routing Number as assigned by Thomson 
Financial Publishing (with CheckDigit) is used to identify 
the DFI in which the Receiver maintains his account or a 
Routing Number assigned to a federal government agency 
by the Federal Reserve. 

ENR: This field contains the Routing Number assigned to 
a Federal Government Agency for the purpose of the 
automated enrollment process. Any entry with a dollar 
value directed to that Routing Number in error is not 
subject to compensation rights as provided in these Rules. 



RecordSize (all Standard Entry Class Codes): 3 Positions 
- File Header Record - Mandatory 

The Record Size Field indicates the number of characters 
contained in each record. At this time, the value "094" 
must be used. 



Refused Acknowledgment Code (Refused ACK, Refused 
ATX): 2 positions - Corporate Entry Detail Record, Entry 
Detail Record - Mandatory 

A standard code used by an ODFI to describe the reason 
for refusing an acknowledgment entry. 



Refused COR Code (refused COR): 
Addenda Record - Mandatory 



3 Positions 



A standard code used by the RDFI to designate the reason 
for refusing a notification of change entry. 



Return Reason Code (returns, dishonored returns, 
contested dishonored returns): Addenda Record - 
Mandatory; 3 Positions - Return Entry; 2 Positions - 
Dishonored Return Entry and Contested Dishonored 
Return Entry 

A standard code used by an ACH Operator or RDFI to 
describe the reason for returning an entry. In a 
Dishonored Return entry and Contested Dishonored 
Return entry, only the numeric portion of the code is used. 




Record Type Code (all Standard Entry Class Codes): 1 
Position - All Record Formats - Mandatory 

See Record Type Codes under currently assigned "Code 
Values" in this Appendix Two. 



Reference Code fall Standard Entry Class Codes): 8 
Positions - File Header Record - Optional 

This field is reserved for information pertinent to the 
Originator. 

ADV: This field will contain "ADV FILE". 



Reference Information #i (POS, SHR): 7 Positions - 
Addenda Record - Optional 

This field may be used for additional reference numbers, 
identification numbers, or codes which the merchant 
needs to identify the particular transaction or customer. 



Reference Information #2 fFOS. SHRV 3 Positions - 
Addenda Record - Optional 

This Field may be used for additional reference numbers, 
identification numbers, or codes which the merchant 
needs to identify the particular transaction or customer, 



Return Settlement Date (dishonored returns, contested 
dishonored returns): 3 Positions - Addenda Record - 
Mandatory 

The Return Settlement Date is used in the Automated 
Dishonored Return format. The data for this field is 
obtained from the Settlement Date field in the 
Company/Batch Header of the Return entry. 



Return Trace Number (dishonored returns, contested 
dishonored returns): 15 Positions - Addenda Record - 
Mandatory 

The Return Trace Number is used in the Automated 
Dishonored Return format. The data for this field is 
obtained from positions 80 - 94 of the Addenda Record or 
positions 80-94 of the Entry Detail Record of the Return 
entry. 



Routing Number of A CH Operator (ADV): 8 positions - 
Entry Detail Record - Mandatory 

This field contains the Routing Number of the ACH 
Operator that is sending the file. 



Sequence Number Within Batch (ADV): 4 positions - 
Entry Detail Record - Mandatory 

This field contains the sequence number of an Entry 
Detail Record within a batch of entries. 
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Service Class Code (all Standard Entry Class Codes): 3 
Positions - Corr^any/Batch Heade 
Company/Batch Control Record - Mandatory 

The Service Class Code (BAI Specifications) identifies 
the general classification of dollar entries to be 
exchanged. This standard has been recommended to 
facilitate inter-DFI transmission of data. ACH entries 
have been assigned Service Class Code series 200-299. 
(See Service Class Codes under currently assigned "Code 
Values" in this Appendix Two.) 



Settlement Date (all Standard Entry Class Codes): 3 
Positions - Company/Batch Header Record - Inserted by 
Receiving ACH Operator 

The scheduled Settlement Date for a batch of entries shall 
be inserted by the Receiving ACH Operator. This is the 
date on which the Participating D.FI or its correspondent 
is scheduled to be debited or credited by the Federal 
Reserve. For all entries except return entries and check 
safekeeping entries, the Settlement Date inserted by the 
Receiving ACH Operator will be the same as the effective 
entry date unless the date specified is the same as or 
earlier than the banking day of processing as established 
by the Originating ACH Operator (the processing date), in 
which case the scheduled Settlement Date will be the next 
# banking day following the processing date. Returns, 
dishonored returns, and contested dishonored returns will 
be settled by the ACH Operator no earlier than the 
Effective Entry Date contained within the original entry, 
as it appears in me return entry Company/Batch Header 
Record. The return of an entry that contains an invalid or 
stale Effective Entry Date will be settled by the ACH 
Operator at the earliest opportunity (i.e., same banking 
day of processing or next banking day following the 
processing date. Notifications of Change and TRC/TRX 
entries will be settled at the earliest opportunity, i.e. , same 
banking day of processing or next banking day following 
the processing date. For purposes of this provision, the 
term "banking day" refers to a day on which the 
Originating ACH Operator's facility is being operated. 



ACH accounting information in machine readable format 
to facilitate the automation of accounting information for 
Participating DFIs. Automated accounting advice is an 
optional service to be provided by ACH Operators and 
must be requested by those DFIs desiring this service. 



Standard Entry Class (all Standard Entry Class Codes): 
3 Positions - Company/Batch Header - Mandatory 

This field is a mnemonic which permits various kinds of 
entries to be distinguished. 

ACK: ACH Payment Acknowledgment- The alphabetic 
mnemonic to identify an acknowledgment of receipt by 
the RDFI of a corporate credit payment originated using 
the CCD format. An ACK entry may be accompanied by 
one addenda record which relays information about the 
financial EDI credit payment using the ANSI ASCX12 
REF (Reference) data segment 

ADV. Automated Accounting Advice - The alphabetic 
mnemonic to identify automated accounting advices of 



ARC: Accounts Receivable Entiy - The alphabetic 
mnemonic to identify a Single Entry debit entry initiated 
by an Originator to a Consumer Account of the Receiver 
pursuant to a source document, as set forth in subsection 
2.9.1 (Source Documents), provided to the Originator by 
the Receiver via the U.S. mail or at a dropbox location. 

ATX: Financial EDI Acknowledgment - Thv alphabetic 
mnemonic to identify an acknowledgment of receipt by 
the RDFI of a corporate credit payment originated using 
the CTX format. An ATX entry may be accompanied by 
one addenda record which relays information about the 
financial EDI credit payment using the ANSI ASC XI 2 
REF (Reference) data segment. 

CBR: Corporate Cross-Border Payment - The alphabetic 
mnemonic to identify a credit or debit entry initiated to 
effect a payment exchanged between payment system 
participants of different countries, via an Originating 
Gateway Operator and a Receiving Gateway Operator, to 
or from a corporate account of the Receiver. A CBR 
entry must by accompanied by one Addenda Record that 
contains foreign payment information. 

CCD: Cash Concentration or Disbursement ■ - The 
alphabetic mnemonic to identify debits and credits 
initiated by an Originator to consolidate funds of such 
Originator from its branches, franchises or agents, or from 
other organizations or to fund the accounts of its branches, 
franchises or agents, or of other organizations. A CCD 
entry may be accompanied by one Addenda Record that 
relays information in payment related ANSI ASC X12 
data segments or NACHA-endorsed banking conventions. 

.'CHS: Customer Initiated Entry - The alphabetic 
mnemonic to identify credit entries (other than PPD or 
MTE entries) initiated by an Originator (usually an 
individual or a service provider on behalf of an 
individual), usually to pay an obligation of such 
individual. A CIE entry may be accompanied by one 
Addenda Record that relays information using payment 
related ANSI ASC X12 data segments. 

COR: Automated Notification of Change or Refused 
Automated Notification of Change - The alphabetic 
mnemonic to identify an automated notification of change 
or a refused automated notification of change. A COR 
entry must be accompanied by an Addenda Record to 
specify changed information. 

CTX: Corporate Trade Exchange - The alphabetic 
mnemonic to identify credit or debit entries originated by 
an Originator to pay or collect an obligation of such 
Originator and destined for the account of another 
organization. CTX entries may be accompanied by 
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Addenda Records that relay information formatted in 
accordance with ANSI ASC X12.5 and X12.6 syntax, an 
ASC XI 2 transaction set containing a BPR or BPS data 
segment, or payment related UN/EDIFACT syntax. 

DNE: Death Notification Entry \ - The alphabetic 
mnemonic to identify a notice initiated by an agency of 
the Federal Government to notify an RDFI of the death of 
a Receiver. A DNE entry must be accompanied by one 
Addenda Record that relays information, such as date of 
death and social security number of the Receiver using a 
NACHA endorsed banking convention. 

ENR: Automated Enrollment Entry ■ - The alphabetic 
mnemonic to identify ACH enrollment entries originated 
by a DFI at the request of an account holder at the DFI. 
Entries are sent to a Federal Government Agency and 
must include at least one addenda record that relays 
information pertaining to the account holder on whose 
behalf the Automated Enrollment entry is initiated. (See 
Payment Related Information in this Appendix Two.) 

MTE: Machine Transfer Entry > - The alphabetic 
mnemonic to identify credit or debit entries initiated at an 
electronic terminal, as defined in Regulation E of The 
Board of Governors of the Federal Reserve System, to 
effect a transfer of funds to or from a deposit account of 
an Originator maintained with a RDFI, i.e., ATM cash 
deposits and withdrawals. NOTE: Credit entries so 
initiated to the accounts of third parties are CIE entries 
and are to be formatted as such. An MTE entry must be 
accompanied by an Addenda Record to provide terminal 
location, city, state and other required information. 

PBR: Consumer Cross-Border Payment- The alphabetic 
mnemonic to identify a credit or debit entry initiated to 
effect a payment exchanged between payment system 
participants of different countries, via an Originating 
Gateway Operator and a Receiving Gateway Operator, to 
or from a Consumer Account of the Receiver. A PBR 
entry must be accompanied by one Addenda Record that 
contains foreign payment information. 

POP: Point-of-Purchase Entry - The alphabetic 
mnemonic to identify a Single Entry debit initiated by an 
Originator pursuant to a source document as set forth in 
Article Three, subsection 3.8.1 (Source Documents), 
provided to the Originator by the Receiver at the point-of- 
purchase to effect a transfer of funds from a Consumer 
Account of the Receiver. This type of entry may only be 
used for non-recurring, in-person (i.e., at the point-of- 
purchase) entries for which there is no standing 
authorization with the merchant for the origination of 
ACH entries to the Receiver's account. 

POS: Point of Sale Entry - The alphabetic mnemonic 
used to identify debit entries initiated at an electronic 
terminal as defined in Regulation E of The Board of 
Governors of the Federal Reserve System to pay an 
obligation incurred in a point-of-sale transaction, or to 
effect a transfer of funds from a deposit account (i.e., a 



point-of-sale terminal cash withdrawal), and reversing, 
adjusting, and other credit entries relating to such debit 
entries, transfer of funds or obligations. POS entries are 
originated in a non-shared system in which no agreement 
other than these Rules exists between the ODFI and the 
RDFI, and in which transactions are typically initiated by 
use of a merchant issued plastic card. A POS entry must 
be accompanied by an Addenda Record to provide 
terminal location, city, state, and other required 
information. 

PPD: Prearranged Payment and Deposit Entry > - The 
alphabetic mnemonic to identify credit or debit entries 
(other than MTE or POS entries) initiated by an 
Originator (usually a business entity) pursuant to a 
standing or single entry authorization from its customer or 
employee (usually, in the case of debit entries, to pay an 
obligation owed by such customer). A PPD entry may be 
accompanied by one Addenda Record that relays 
information using payment related ANSI ASC X12 data 
segments or NACHA endorsed banking conventions. 

RCK: Re-presented Check Entry - The alphabetic 
mnemonic to identify a Single Entry debit constituting a 
presentment notice of an item eligible under Article Two, 
Section 2.8 (Re-presented Check Entries). An RCK entry 
is an item as defined by Revised Article 4 of the Uniform 
Commercial Code (1990 Official Text) only for the 
limited purposes of presentment as set forth in Article 4- 
1 10(c) and notice of dishonor as set forth in Article 4- 
301(a)(2). 

SHR: Shared Network Transaction - The alphabetic 
mnemonic used to identify debit entries initiated at an 
electronic terminal as defined in Regulation E of The 
Board of Governors of the Federal Reserve System to pay 
an obligation incurred in a point-of-sale transaction, or to 
effect a transfer of funds from a deposit account (i.e., 
point-of-sale terminal cash withdrawal), and reversing, 
adjusting, and other credit entries relating to such debit 
entries, transfer of funds or obligations. SHR entries are 
originated in a shared system where an agreement, in 
addition to these Rules, exists between the ODFI and 
RDFI, and in which the transactions are typically initiated 
by the use of a plastic card issued by the Receiver's DFI. 
Ail SHR entry must be accompanied by an Addenda 
Record to provide terminal location, city, state, and other 
required information. 

TEL: Telephone-Initiated Entry - The alphabetic 
mnemonic used to identify a Single-Entry debit initiated 
by an Originator pursuant to an oral authorization 
obtained over the telephone to effect a transfer of funds 
from a Consumer Account of the Receiver. This type of 
entry may only be used for a Single Entry for which there 
is no standing authorization for the origination of ACH 
entries to the Receiver's account. A TEL entry may only 
be used when there is an Existing Relationship between 
the Originator and the Receiver, or, when there is not an 
Existing Relationship between the Originator and the 
Receiver, when the Receiver initiates the telephone call. 
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TEC: Truncated Entry - The alphabetic mnemonic to 
identify truncated checks being safekept by the keeper 
bank (Originator) as defined by a check truncation 
program.. 

TEX: Truncated Entries Exchange - The alphabetic 
mnemonic to identify truncated checks being safekept by 
the keeper bank (Originator) as defined by a check 
truncation program. The TRX format allows financial 
institutions to use a single entry to carry information from 
multiple checks. TRX entries must be accompanied by 
Addenda Records that relay information formatted in 
National Association for Gheck Safekeeping syntax. 

WEB : Internet-Initiated Entry - The alphabetic mnemonic 
to identify debit entries initiated by an Originator pursuant 
to an authorization that is obtained from the Receiver via 
the Internet to effect a transfer of funds from a Consumer 
Account of the Receiver. 

XCK: Destroyed Check Entry - The alphabetic mnemonic 
to identify debit entries initiated in the event an item 
eligible for Article Two, section 2.7 (Destroyed Check 
Entries) is contained within a cash letter that is lost, 
destroyed, or otherwise unavailable to and cannot be 
obtained by the ODFI. 



Terminal City : 15 Positions '■ - Addenda Record - 
Required (MTE, POS, SHR); 4 Positions - Entry Detail 
Record - Mandatory (POP) 

This field identifies the city, town, village or township in 
which an electronic terminal is located. 

POP: This field contains a truncated name or abbreviation 
to identify the city, town, village, or township in which the 
electronic terminal is located. 



Terminal Identification Code (MTE, POS, SHR): 6 
Positions - Addenda Record - Required 

This field identifies an electronic terminal with a unique 
code which allows a terminal owner and/or switching 
network to identify the terminal at which a given entry 
originated. 



Terminal Location (MTE, POS, SHR): 27 Positions - 
Addenda Record- Required 

This field identifies the specific location of a terminal 
(i.e., street names of an intersection, address, etc.) in 
accordance with the requirements of Regulation E of the 
Board of Governors of the Federal Reserve System. 



Terminal State : 2 Positions - Addenda Record - 
Required (MTE, POS, SHR); 2 Positions - Entry Detail 
Record - Mandatory (POP) 

This field identifies the state of the United States in which 
an electronic terminal is located. 



Total Amount (ATX, CTX, TRX, refused ATX, returns, 
dishonored returns, contested dishonored returns, COR, 
refused COR): 10 Positions - Corporate Entry Detail 
Record -Mandatory 

The net dollar value of all items paid to the same business 
is the total amount. This amount represents the total 
dollar value of all the items included in Total Number of 
Items . The RDFI posts this total amount to the 
appropriate account authorized by the Originator. 

ATX: The value of this field is always zero. 



Total Debit or Credit Entry Dollar Amount : 12 positions 
- Company/Batch Control and File Control Records - 
Mandatory (all Standard Entry Class Codes except AD V); 
20 positions - Company/Batch Control and File Control 
Records - Mandatory (ADV) 

These fields contain accumulated Entry Detail debit and 
credit totals within a given batch (Company/Batch Control 
Record) and accumulated Company/Batch Control Record 
debit and credit totals within a given file (File Control 
Record). 



Trace Number (ACK, ARC, ATX, CBR, CCD, CIE, 
CTX, DNE, ENR, MTE, PBR, POP, POS, PPD, RCK, 
SHR, TEL, TRC, TRX, WEB, XCK, refused ACK, 
refused ATX, returns, dishonored returns, contested 
dishonored returns, COR, refused COR): 15 Positions - 
Entry Detail Record, Corporate Entry Detail Record, and 
Addenda Records -Mandatory 

A Trace Number, assigned by the ODFI in ascending 
sequence, is included in each Entry Detail Record, 
Corporate Entry Detail Record, and Addenda Record. 
Trace Numbers uniquely identify each entry within a 
batch in an ACH input file. In association with the Batch 
Number, Transmission (File Creation) Date, and File ID 
Modifier, the Trace Number uniquely identifies an entry 
within a given file. For Addenda Records, the Trace 
Number will be identical to the Trace Number in the 
associated Entry Detail Record, since the Trace Number 
is associated with an entry or item rather than a physical 
record. 

Throughout the entire processing cycle (from ODFI to 
RDFI) the Trace Number is retained with the entry record. 
The Trace Number is critical in routing returned entries 
from the RDFI back to the ODFI through the ACH. 
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Since it is possible, although undesirable, for an ODFI to 
duplicate Trace Numbers on separate files or within 
different batches submitted during the same processing 
date, the File ID Modifier contained in the ODFI's File 
Header Record should also be referenced when the ODFI 
is tracing returned entries. 

The Trace Number is constructed as follows: 



Transaction Serial Number (MTE. POS. SHIP: 6 
Positions - Addenda Record - Required 

This number is assigned by the terminal at the time the 
transaction is originated. The number, with the Terminal 
Identification Code, serves as an audit trail for the 
transaction and is usually assigned in ascending sequence. 



Positions 

01-08 

09-15 



Routing Number of ODFI. 
Entry Detail Sequence Number - The item 
number assigned in ascending order to entries 
within each batch. Provisions should be made 
by the ODFI to avoid duplication of Trace 
Numbers if multiple data files are prepared on 
the same day. Trace Numbers are not required 
to be contiguous. 



Transaction Code (ACK. ADV, ARC, ATX, CBR, CCD, 
CIE, CTX, DNE, ENR, MTE, PBR, POP, POS, PPD, 
RCK, SHR, TEL, TRC, TRX, WEB, XCK, refused ACK, 
refused ATX, returns, dishonored returns, contested 
dishonored returns, COR, refused COR): 2 Positions - 
Entry Detail Record - Mandatory 



Transaction Codes have been defined to identify various 
types of debit and credit entries. POS entries will utilize 
existing debit/credit Transaction Codes. (See Transaction 
Codes under currently assigned "Code Values" in this 
Appendix Two.) 



Transaction Time (MTE): 6 Positions - Addenda Record 
-Required 

This field is used to identify the time of day a transaction 
originated at a terminal in HHMMSS. 



Transaction Type Code (CBR, PBR): 3 Positions - 
Addenda Record - Required 

This field contains a three-character code used to identify 
the type of transaction. Code values are "ANN" 
(Annuity), "BUS" (Business/Commercial), "DEP" 
(Deposit), "LOA" (Loan), "MIS" (Miscellaneous), 
"MOR" (Mortgage), "PEN" (Pension), "RLS" 
(Rent/Lease), "SAL" (Salary/Payroll), 'TAX" (Tax). 



APPENDIX THREE - 
SPECIFICATIONS FOR 
DATA ACCEPTANCE 




Transaction Date (MTE, POS, SHR): 
Addenda Record - Required 



4 Positions - 



This date, expressed MMDD, signals the date on which 
the transaction occurred. 



Transaction Description (MTE): 
Record - Required 



7 Positions - Addenda 



This field describes the transaction in accordance with 
Regulation E. Possible descriptions include: 

CHK-DEP (Checking Deposit) 

SAV--DEP (Savings Deposit) 
PAYMENT.. .. 

CHK--SAV (Transfer: checking to savings) 

SAV--CHK (Transfer: savings to checking) 

CHK--WDL (Checking Withdrawal) 

SAV--WDL (Savings Withdrawal) 

ADVANCE (Credit Card Cash Advance) 



The data acceptance criteria set forth below apply to 
entries submitted by Sending Points or exchanged 
between ACH Operators. Failure to meet such criteria 
will result in the rejection of an entire file, batch, or an 
individual entry by the ACH Operator. A Sending Point 
must select either the file level reject option or the batch 
level reject option and notify the ACH Operator of its 
choice. 

SECTION 3.1 File Acknowledgment 

Each Originating ACH Operator generates an 
acknowledgment for every file submitted for processing. 
The acknowledgment is in the form of a message or report 
transmitted or made available to the Sending Point 
electronically. The ACH Operatormakes the 
acknowledgment available as soon as possible after the 
completion of the edits listed in sections 3.4 (Automatic 
File Rejection), 3 . 5 (Automatic Batch Rejection), and 3 .6 
(Automatic Entry Detail Return Entry) of this Appendix 
Three. At a rrinimum, the acknowledgment includes 
information from the following fields within the Sending 
Point's File Header and File Control Records: 



Immediate Origin 

Immediate Origin Name (if available) 



OR 85 



APPENDIX THREE 



2005 OPERATING RULES 




•File Creation Date 

• File Creation Time (if available) 

• File ID Modifier 

• File Entry/Addenda Count 

• Total Debit Entry Dollar Amount in File 

• Total Credit Entry Dollar Amount in File 
•■ File Batch Count 

The acknowledgment also contains the date and time the 
file was processed by the ACH Operator and, if the file 
was rejected, the reason for the rejection. If the file was 
not rejected, but one or more batches were rejected by the 
ACH Operator, the acknowledgment will also contain the 
following information about each rejected batch: 



Originating DFI Identification 
Originating DFI Name (if available) 
Company Name 
Company Identification 
Batch Number 
Effective Entry Date 
Batch Entry/Addenda Count 
Total Debit Dollar Amount 
Total Credit Dollar Amount 
Reason for Batch Rejection 



SECTION 3.2 File Level Reject Option 

If the Sending Point chooses the file level reject option, 
any condition which would cause a batch to be rejected 
will cause the entire file to be rejected. Automatic file 
rejections, as described in section 3.4 (Automatic File 
Rejection) of this Appendix Three, are not affected by this 
option. 

.■SECTION 3.3 Batch Level Reject Option 

If the Sending Point chooses the batch level reject option, 
any condition that would cause only a batch to be rejected 
will allow the ACH Operator to accept the file but to 
reject the erroneous batch as described in section 3.5 
(Automatic Batch Rejection) of this Appendix Three. 

SECTION 3.4 Automatic File Rejection 

The following error conditions will always cause the 
entire file to be rejected: 

•' The file cannot be successfully read, e.g., data read 
failures, improper block size, presence of invalid header 
labels, hardware/software error checks indicated. 

V The file contains any "undefined" record type. 

• The File Header Record does not contain the number of 
a valid Sending Point or ACH Operator (a point defined 
on the ACH Operator routing table file). 

* The file is "out-of-balance," i.e., one or more of the 
following conditions exist: 



--the summation of the counts, hash totals, and total 
dollars on Company/Batch Control Records does 
not agree with the File Control Record. 

■'—'■ the actual number of blocks or batches in the file 
doe s not agree with the File Control Record counts . 

• Mandatory fields in the File Header Record are not 
valid: 

-- File ID Modifier is not uppercase A-Z or 0-9. 

- Record size is not 094. 

-- Blocking Factor is not 10. 

-- Format Code is not 1 . 

• The sequence of records in the file is incorrect. 

• The Immediate Origin, File Creation Date, File 
Creation Time, and File ID Modifier are equal to that of 
a previously accepted file. 

SECTION 3.5 Automatic Batch Rejection 

The following error conditions will cause the batch to be 
rejected if batch level rejection has been specified, or will 
cause the entire file to be rejected if file level rejection has 
been specified: 

' • The batch contains invalid characters (i.e., characters 
not specified in Appendix One, ACH File Exchange 
Specifications). 

•■ Except for files coming from another ACH Operator, 
the ODFI Identification in the Company/Batch Header 
Record is not the routing number of a valid ODFI. 

• The Service Class Code in a Company/Batch Header 
Record is other than a currently valid code. 



The Trace Numbers on the file are not in ascending 
sequence within a batch. 

The Transaction Codes in Entry Detail Records are 
invalid. 

The ODFI of a TRC/TRX batch is not a participant in 
a check truncation program. 

The Amount field in an Entry Detail Record is 
non-numeric. 



The sequence of records in the batch is incorrect. 

The batch is "out-of-balance," i.e., the counts, hash 
totals, or dollars in the Company/Batch Control 
Records do not agree with the summation of the entries 
for the batch. 

The Company Name is all spaces or all zeros. 
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8 The Company Entry Description is all spaces or all 
■'■' zeros. 

• The Company Identification is all spaces or all zeros. 

•' The Originator Status Code is not equal to "2" for DNE 
if the Transaction Code is 23 or 33. 

*. The Standard Entry Class Code in the Company/Batch 
Header Record is other than a currently valid code. 

■ •' . ■ The Service Class Code in the Company/B atch Control 
Record is not the same as that in the Company/Batch 
Header Record. 

• The first eight positions of the Trace Number in an 
Entry Detail Record are not the same as the ODFI 
Routing Number in the corresponding (immediately 
preceding) Company/Batch Header Record. 

• The Transaction Code in an Entry Detail Record is not 
valid for the Service Class Code in the Company/Batch 
Header Record. Either a debit Transaction Code is in 
a credit batch, or a credit Transaction Code is in a debit 
batch. 

• The Transaction Code in an Entry Detail Record is not 
valid for the Standard Entry Class Code in the 
Company/Batch Header Record. For Standard Entry 
Class Code COR, the Transaction Code must be 21, 26, 
31, 36, 41, 46, 51, or 56. For Standard Entry Class 
Code DNE, the Transaction Code must be 2 1 , 23 , 3 1 , or 
33. 

• Return and non-return transactions are in the same 
batch. 

• Return, dishonored return, and/or contested dishonored 
return transactions are in the same batch. 

• The Batch Number in the Company/Batch Header 
Record is non-numeric. 

• The Batch Number in the Company/Batch Control 
Record is non-numeric. 

• The Batch Number in the Company/Batch Control 
Record is not the same as the Batch Number in the 
Company/Batch Header Record. 

SECTION 3.6 Automatic Entry Detail Return Entry 

ACH Operators use return reason codes for the following 
error conditions. These error conditions will never cause 
the entire file to be rejected but will always cause the 
entry detail record to be returned using an Addenda 
Record with an Addenda Type Code of "99": 



Rl 3 RDFI Not Qualified to Participate 

9 RDFI not qualified to participate or the Routing 
Number is not valid. 

R18 Improper Effective Entry Date 

■" • ■ The effective entry date for a credit entry is more than 
two banking days after the banking day of processing 
as established by the Originating ACH Operator. 

• The effective entry date for a debit entry is more than 
one banking day after the processing date. 

R19 Amount Field Error 

'■• Amount field is non-numeric. 

• ' Amount field is not zero in a prenotification, DNE, 
ENR, Notification of Change, Refused Notification of 
Change, or zero dollar entry. 

'• Amount field is zero in an entry other than a 
prenotification, DNE, ENR, Notification of Change, 
Refused Notification of Change, Return, Dishonored 
Return, Contested Dishonored Return, or zero dollar 
entry. 

R25 Addenda Error 

'• Addenda Record Indicator value is not or 1. 

• Addenda Record Indicator value is but Addenda 
Record follows. 

■':• Addenda Record Indicator value is 1 but no Addenda 
Record follows. 

.• Addenda Record Indicator on a CTX or TRX entry is 
and Number of Items Paid or Number of Addenda 
Records is not zero. Addenda Record Indicator is 1 
and Number of Items Paid or Number of Addenda 
Records is 0. 

e The Addenda Record Indicator for notifications of 
change, refused notifications of change, returns, 
dishonored returns, contested dishonored returns, 
CBR, DNE, ENR, MTE, PBR, POS, SHR, TRX, and 
zero dollar entries other than prenotifications is not 
equalto'TV 

■:'■'•' Addenda Type Code is not valid if not equal to "0 1 " 
for CBR or PBR entries, "02" for MTE, 5 POS, or SHR 
entries; "05" for ACK, ATX, CCD, CIE, CTX, DNE, 
ENR, PPD, TRX, or WEB entries; "98" on 
Automated Notification of Change or Automated 
Refused Notification of Change; or "99" or "05" 
(TRX only) on Automated Return, Automated 
Dishonored Return, or Automated Contested 
Dishonored Return Entries. 
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• Total number of Addenda Records exceeds the 
maximum number allowable (9,999) per Entry Detail 
Record (CTX, ENR, or TRX). 

• The number of Addenda Records exceeds one (1) for 
GBR, CCD, CIE, DNE, MTE, PBR, POS, PPD, 
SHR, WEB, notifications of change, refused 
notifications of change, returns, dishonored returns, 
and contested dishonored returns. 

• Addenda Sequence Number is not valid. 

• The actual number of addenda records is not equal to 
the Number of Addenda Records in the Corporate 
Entry Detail Record (CTX) or the Entry Detail 
Record (ENR, TRX). 

R26 Mandatory Field Error 

• Individual Name contains all spaces or all zeros 
(MTE Entry). 

■ • Individual Identification Number contains all spaces 
or all zeros (MTE entries or CIE entries). 

■.■■• Check Serial Number contains all spaces or all zeros 
(ARC entries, POP entries, RCK entries, or XCK 
entries). 

.• Terminal City contains all spaces or all zeros (POP 
entries only). 

;■■; • Terminal State contains all spaces or all zeros (POP 
entries only). 

' ■ : . • Card Transaction Type Code is not a valid code as 
specified in Appendix Two (ACH Record Format 
Specifications) (POS and SHR entries only). 



Number of Addenda Records in a Corporate Entry 
Detail Record is not numeric. 

The Return Reason Code field for return entries, the 
Dishonored Return Reason Code field for dishonored 
returns, or the Contested Dishonored Return Reason 
Code field for contested dishonored returns does not 
contain a valid code as specified in Appendix Five 
(Return Entries). 

The Change Code field for notification of change 
entries or the Refused COR Code field for refused 
notification of change entries does not containa valid 
code as specified in Appendix Six (Notification of 
Change). 

On a Notification of Change or Refused Notification 
of Change, the Corrected Data field is blank, or on a 
Refused Notification of Change, the Change Code is 
not a currently assigned value (see Appendix Six, 
Notification of Change) or the COR Trace Sequence 
Number field is not numeric. A Refused Notification 



of Change is denoted by a valid Refused COR Code 
in the Refused COR Code field. See Appendix Six 
for a list of valid codes. 

• In a dishonored return or contested dishonored return, 
the Return Trace Number is not numeric, the Return 
Settlement Date is not a valid Julian date in the range 
001-366, or the Return Reason Code is not a 
currently assigned value for Returns. 

° In a contested dishonored return, the Dishonored 
Return Trace Number is not numeric, the Dishonored 
Return Settlement Date is not a valid Julian date in 
the range 00 1 -366, or the Dishonored Return Reason 
Code is not a currently assigned value for dishonored 
returns. 

V In a contested dishonored return with Contested 
Dishonored Return Reason Code R73 (timely original 
return), the Qriginal Settlement Date is not a valid 
Julian date in the range 00 1-366, or the Date Original 
Entry Returned is not a valid date. 



R27 Trace Number Error 

Y Original Entry Trace Number is not present in the 
Addenda Record on an automated return. 

•■ Trace Number of an Addenda Record is not the same 
as the Trace Number of the preceding Entry Detail 
Record. 

R28 Routing Number Check Digit Error 

> The Check Digit for a Routing Number is not valid. 

R30 RDF I Not Participant in Check Truncation 
Program 



R32 RDFI Non-Settlement 

V The RDFI is not able to settle the entry. 

R34 Limited Participation DPI 

e The RDFFs participation has been limited by a 
federal or state supervisor. 

R35 Return of Improper Debit Entry 

Y ACH debit entries (with the exception of reversals) 
are not permitted for use with the CIE Standard Entry 
Class Code. 

• ACH debit entries (with the exception of reversals) 
are not permitted to loan accounts. 
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R36 Return of Improper Credit Entry 

• ACH credit entries (with the exception of reversals) 
are not permitted for use with the ARC Standard 
Entry Glass Code. 

• ACH credit entries (with the exception of reversals) 
are not permitted for use with the POP Standard 
Entry Class Code. 

• RCK entries must be limited to debits to demand 
accounts, with the exception of reversals to correct 
erroneous entries. 

> ACH credit entries (with the exception of reversals) 
are not permitted for use with the WEB Standard 
Entry Class Code. 

8 ACH credit entries (with the exception of reversals) 
are not permitted for use with the TEL Standard 
Entry Class Code. 

Creation of the resulting automated return entries shall be 
in accordance with the specifications in Appendix Five 
(Return Entries). 



APPENDIX FOUR - MINIMUM 
DESCRIPTION STANDARDS 



The above requirements do not apply to Receivers' 
passbook accounts which may not be accessed by 
electronic fund transfers other than preauthorized credit 
transfers. However, they do apply whether or not 
Regulation E imposes certain of those requirements on a 
person other than the RDFI and whether or not the 
Regulation exempts a Participating DPI from all such 
requirements with respect to certain types of entries. 

For Accounts Receivable (ARC) Entries, Destroyed 
Check Entries (XCK), Re-presented Check (RCK) Entries 
and Point-of-Purchase (POP) Entries, these rules require 
that, in addition to the information noted above, the RDFI 
also provide the Receiver with the following information 
relating to the entry: ^ 

(a) Check Serial Number. 

NACHA strongly recommends, but these Rules do not 
require, that a RDFI also send or make available to each 
of its Receivers the following additional information with 
respect to a credit or debit entry made to such Receiver's 
account. 

(a) Company Descriptive Date 

(b) Individual Identification Number/ Identification 
Number 

Terms used herein shall have the meanings set forth in 
Appendix Two (ACH Record Format Specifications) of 
these Rules. 




These rules require each RDFI to send or make available 
to each Receiver specific minimum descriptive 
information concerning each credit or debit entry to the 
Receiver's account. This descriptive information, which 
is consistent with the requirements of Section 205.9(b) of 
Federal Regulation E, is as follows : 

(a) Posting date to customer's account 

(b) Dollar amount of the entry 

(c) Company name 

(d) Company entry description 

(e) Type of account (e.g., checking) 

(f) Number of the account 

(g) Amount of any charges assessed against the account 
for electronic fund transfer services 

(h) Balances in the customer's account at the beginning 

and at the close of the statement 
(i) Terminal Identification Code (MTE, POS, and SHR 

entries) 
(j) Terminal Location (MTE, POS, and SHR entries) 
(k) Terminal City (MTE, POP, POS, and SHR entries) 
(1) Terminal State (MTE, POP, POS, and SHR entries) 
(m) Address and telephone number to be used for 

inquiries or notices of errors preceded by "Direct 

Inquiries To" or similar language 



APPENDIX FIVE - RETURN 

ENTRIES ; 



Except as otherwise provided in Article Six, section 6.1 
(Return of Entries) of these rules, an RDFI may return 
entries for any reason, provided it uses an appropriate 
Return Reason Code as specified in this Appendix and, if 
it uses Return Reason Code Rl 1 or R17, provided it 
specifies the reason for the return. If no appropriate 
Return Reason Code is specified in this Appendix Five, 
the RDFI shall use the code which most closely 
approximates me reason for return. 

SECTION 5.1 Automated Return Entries 

NOTE: Throughout this section, DFIs will always be 
designated by their original names. For example, the 
ODFI is the DFI that initially prepared the original entry, 
and which will eventually have the Automated Return 
Entry delivered to it. The RDFI is the DFI that was 
supposed to receive the original entry and will usually be 
preparing the Automated Return Entry. In some cases an 
Automated Return Entry may be prepared by an 
intervening ACH Operator if the entry cannot be delivered 
or if it contains an erroneous condition. 
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When an Automated Return Entry is prepared, the original 
Company/Batch Header Record, the original Entry Detail 
Record, and the Company/Batch Control Record are 
copied for return to the Originator. (NOTE: This 
includes the original SEC code found in Field 5 1-53 of the 
Company Batch Header record.) 

The Automated Return Entry is looked at as a new entry, 
generated because the original entry failed to accomplish 
its intended purpose. Thus, these entries should be 
assigned new batch and trace numbers, new identification 
numbers for the returning institution, appropriate 
transaction codes, and so on. 

The File Creation Date is of use to the ODFI when the 
entry is being returned by the first ACH Operator 
processing the file submitted/ Otherwise, this data 
element is for a file created outside the organization of the 
ODFI and the information is not helpful. The ODFI can 
determine if the date is from its own file by looking at 
Field 12 of the Company/Batch Header Record, which 
now carries the identification of the institution preparing 
the return entry. 

There is nothing required in the format that limits the 
number of Entry Detail Record/Addenda Record pairs to 
one for each batch. Multiple entry return entry batches 
certainly may be generated from one original batch. 

SECTION 5.2 Non-Automated Return Entries 

An ACH Operator that agrees to accept non-automated 
return entries must convert them to the automated format 
at the point of entry into the system. A return converted 
to the automated format must bear the original Standard 
Entry Class Code. 

SECTION 5.3 Adjustment Entries 

In compliance with Article Eight, section 8.7 (Adjustment 
Entries) of the Rules, adjustment entries are utilized by an 
RDFI when, upon receiving notice from its Receiver that 
a debit entry was, in whole or part, unauthorized, the 
RDFI credits the amount of such entry to its Receiver's 
account and returns the erroneous entry to the ODFI. 

Adjustment entries shall comply with the format and 
specifications for Return Entries in this Appendix Five. 
In order to qualify as adjustment entries, returns must 
contain one of the Return Reason Codes (either R07 or 
RIO) designated as applicable to adjustment entries. 

SECTION 5.4 Table of Return Reason Codes 

Codes To Be Used by the RDFI for Return Entries 

R01 Insufficient Funds 

The available and/or cash reserve balance is not sufficient 
to cover the dollar value of the debit entry. 



R02 Account Closed 

A previously active account has been closed by action of 
the customer or the RDFI. 

R03 : ..No Account/Unable to Locate Account 

The account number structure is valid and it passes the 
check digit validation, but the account number does not 
correspond to the individual identified in the entry, or the 
account number designated is not an open account. ( Note : 
This Return Reason Code may not be used to return ARC 
entries or POP entries that do not contain an Individual 
Name.) 

R0.4 Invalid Account Number 

The account number structure is not valid. The entry may 
fail the check digit validation or may contain an incorrect 
number of digits. 



£ R05 Reserved [ Unauthorized Debit to Consumer 
Account Using Corporate SEC Code (adjustment 
entries)] 

[A CCD, CTX, or CBR debit entry was transmitted to a 
Consumer Account of the Receiver and was not 
authorized by the Receiver. The Receiver may request 
immediate credit from the RDFI for an unauthorized 
debit The request must be made in writing within fifteen 
(1 \5) days after the RDFI sends or makes available to the 
Receiver information pertaining to that debit entry. The 
Receiver must also provide the RDFI with a written 
statement under penalty of perjury, pursuant to 
subsection 8.6.5 (Receiver's Written Statement Under 
Penalty of Perjury), that the debit entry was not 
authorized by the Receiver. For purposes of this code 
and related Operating Rules provisions, a debit entry was 
not authorized by a Receiver if (I) the authorization 
requirements of Article Two, subsection 2.1.2 (Receiver 
Authorization and Agreement) have not been met; (2) the 
debit entry was initiated in an amount greater than that 
authorized by the Receiver; or (3) the debit entry was 
initiated for settlement earlier than authorized by the 
Receiver. An unauthorized debit entry does not include 
a debit entry initiated with fraudulent intent by the 
Receiver or any person acting in concert with the 
Receiver. An RDFI using this return reason code must 
transmit the return entry by its A CH Operator's deposit 
deadline for th e return en try to be made available to the 
ODFI no later than the opening of business on the 
banking day following the sixtieth calendar day following 
the Settlement Date of the original entry. ] 

R06 Returned per ODFFs Request 

The ODFI has requested that the RDFI return the ACH 
entry. If the RDFI agrees to return the entry, the ODFI 
must indemnify the RDFI according to Article Six 
(Return, Adjustment, Correction, and Acknowledgment of 
Entries and Entry Information) of these Rules. 
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R07 Authorization Revoked by Customer (adjustment 
entries) 

The RDFFs customer (the Receiver) has revoked the 
authorization previously provided to the Originator for 
this particular transaction. The Receiver may request 
immediate credit from the RDFI for an unauthorized 
debit. The request must be made in writing within fifteen 
(15) days after the RDFI sends or makes available to the 
Receiver information pertaining to that debit entry. The 
Receiver must also provide the RDFI with a written 
statement under penalty of perjury that the authorization 
for the debit entry has been revoked by the Receiver. The 
RDFI must return the rescinded transaction to its ACH 
Operator by its deposit deadline for the adjustment entry 
to be made available to the ODFI no later than the 
opening of business on the banking day following the 
sixtieth calendar day following the Settlement Date of the 
original entry. This code and related Operating Rule 
provisions apply to Consumer entries only. ( Note : This 
Return Reason Code may not be used for POP entries, 
Single-Entry WEB entries, or TEL entries.) 

R08 Payment Stopped 

The Receiver of a debit transaction has the right to stop 
payment on any specific ACH debit. A stop payment 
request should be handled in accordance with the 
provisions of Article Eight (Recall, Stop Payment, 
Recredit, and Adjustment) of these Rules. The RDFI 
should verify the Receiver's intent when a request for stop 
payment is made to ensure this is not intended to be a 
revocation of authorization (R07). A stop payment order 
shall remain in effect until the earliest of the following 
occurs: a lapse of six months from the date of the stop 
payment order, payment of the debit entry has been 
stopped, or the Receiver withdraws the stop payment 
order. 

R09 Uncollected Funds 

Sufficient book or ledger balance exists to satisfy the 
dollar value of the transaction, but the dollar value of 
transactions in the process of collection (i.e., uncollected 
checks) brings the available and/or cash reserve balance 
below the dollar value of the debit entry. 

RIO Customer Advises Not Authorized, Notice Not 
Provided, Improper Source Document, or Amount of 
Entry Not Accurately Obtained from Source Document 
(adjustment entries) 

• For entries to Consumer Accounts that are not ARC 
entries, POP entries, or RCK entries, the RDFI has been 
notified by its customer, the Receiver, that the 
Originator of a given transaction has not been 
authorized to debit his account. The Receiver may 
request immediate credit from the RDFI for an 
unauthorized debit. The request must be made in 
writing within fifteen (15) days after the RDFI sends or 
makes available to the Receiver information pertaining 
to that debit entry. The Receiver must also provide the 
RDFI with a written statement under penalty of perjury, 



pursuant to subsection 8,6.5 (Receiver's Written 
Statement Under Penalty of Perjury), that the debit 
entry was not authorized by the Receiver. For purposes 
of this code and related Operating Rules provisions, a 
debit entry was not authorized by the Receiver if ( 1 ) the 
authorization requirements of Article Two, subsection 
2.1.2 (Receiver Authorization and Agreement) have not 
been met; (2) the debit entry was initiated in an amount 
greater than that authorized by the Receiver; or (3) the 
debit entry was initiated for settlement earlier than 
authorized by the Receiver. An unauthorized debit 
entry does not include a debit entry initiated with 
fraudulent intent by the Receiver or any person acting 
in concert with the Receiver. The RDFI must return the 
rescinded transaction to its ACH Operator by its deposit 
deadline for the adjustment entry to be made available 
to the ODFI no later than the opening of business on the 
banking day following the sixtieth calendar day 
following the Settlement Date of the original entry. 
This code and related Operating Rule provisions apply 
to Consumer entries only. 




OR 



• For ARC entries, the RDFI has been notified by its 
customer, the Receiver, that (1) the required notice was 
not provided by the Originator in accordance with 
Article Three, subsection 3.7.1 (Notice Obligation), (2) 
the source document used for the debit entry is 
improper pursuant to subsection 3.7.2 (Source 
Documents), or (3) the amount of the ARC entry was 
not accurately obtained from the source document. The 
Receiver may request immediate credit from the RDFI 
for an ARC entry for the reasons described above. The 
request must be made in writing within fifteen (1 5) days 
after the RDFI sends or makes available to the Receiver 
information relating to that debit entry. The Receiver 
must also provide the RDFI with a written statement 
under penalty of perjury, pursuant to subsection 8.6.5.1 
(Receiver's Written Statement Under Penalty of Perjury 
for ARC Entries), that (1) the required notice was not 
provided, (2) the source document used for the debit 
entry is improper, or (3) the amount of the ARC entry 
was not accurately obtained from the source document. 
An RDFI using this Return Reason Code must transmit 
the return entry by its ACH Operator's deposit deadline 
for the return entry to be made available to the ODFI no 
later than the opening of business on the banking day 
following the sixtieth calendar day following the 
Settlement Date of the ARC entry. 



OR 



For POP entries, the RDFI has been notified by its 
customer, the Receiver, that (1) the Originator of a 
given transaction has not been authorized to debit his 
account, or (2) the source document for the debit entry 
is improper pursuant to subsection 3.8. 1 (Source 
Documents). The Receiver may request immediate 
credit from the RDFI for a POP entry for the reasons 
described above. The request must be made in writing 
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within fifteen (15) days after the RDFI sends or makes 
available to the Receiver information relating to that 
debit entry. The Receiver must also provide the RDFI 
with a written statement under penalty of perjury, 
pursuant to subsection 8.6.5.2 (Receiver's Written 
Statement Under Penalty of Perjury for POP Entries), 
that ( 1 ) the entry was not authorized, or (2) the source 
document for the entry is improper. An RDFI using this 
Return Reason Code must transmit the return entry by 
its ACH Operator's deposit deadline for the return entry 
to be made available to the ODFI no later than the 
opening of business on the banking day following the 
sixtieth calendar day following the Settlement Date of 
the entry. 

Rl 1 Check Truncation Entry Return (Specify) 

To be used when returning a check truncation entry. This 
reason for return should be used only if no other return 
reason code is applicable. The RDFI should use the 
appropriate field in the addenda record to specify the 
reason for return (i.e., "exceeds dollar limit,". "no match 
on ARP," "stale date," etc.): 

R12 Account Sold to Another DFI 

A financial institution may continue to receive entries 
destined for an account that has been sold to another 
financial institution. Because the RDFI no longer 
maintains the account and is unable to post the entry, it 
should return the entry to the ODFI. 

R14 Representative Payee Deceased or Unable to 
Continue in that Capacity 

The representative payee is a person or institution 
authorized to accept entries on behalf of one or more 
other persons, such as legally incapacitated adults or 
minor children. The representative payee is either 
deceased or unable to continue in that capacity. The 
beneficiary is not deceased. 

Rl 5 Beneficiary or Account Holder (Other Than a 
Representative Payee) Deceased 

(1) The beneficiary is the person entitled to the benefits 
and is deceased. The beneficiary may or may not be the 
account holder; or 

(2) The account holder (acting in a non-representative 
payee capacity) is an owner of the account and is 
deceased. 

R16 Account Frozen 

The funds in the account are unavailable due to specific 
action taken by the RDFI or by legal action. 

R17 File Record Edit Criteria (Specify) 

Some fields that are not edited by the ACH Operator are 
edited by the RDFI. If the entry cannot be processed by 
the RDFI, the field(s) causing the processing error must 
be identified in the addenda record information field of 
the return. 



R20 Non-Transaction Account 

The ACH entry destined for a non-transaction account, as 
defined in Regulation D, would include either an account 
against which transactions are prohibited or limited or a 
pass-through where the entry is for a credit union or thrift 
organization and Regulation E descriptive requirements 
cannot be met. 

R21 Invalid Company Identification 

The identification number used in the Company 
Identification Field is not valid. This Return Reason Code 
will normally be used on CIE transactions. 

R22 Invalid Individual ID Number 

In CIE and MTE entries, the Individual ID Number is 
used by the Receiver to identify the account. The 
Receiver has indicated to the RDFI that the number with 
which the Originator was identified is not correct. 

R23 Credit Entry Refused by Receiver 

The Receiver may return a credit entry because one of the 
following conditions exists: (1) a minimum amount 
required by the Receiver has not been remitted; (2) the 
exact amount required has not been remitted; (3) the 
account is subject to litigation and the Receiver will not 
accept the transaction; (4) acceptance of the transaction 
results in an overpayment; (5) the Originator is not known 
by the Receiver; or (6) the Receiver has not authorized 
this credit entry to this account. 

R24 Duplicate Entry 

The RDFI has received what appears to be a duplicate 
entry; i.e., the trace number, date, dollar amount and/or 
other data matches another transaction/This code should 
be used with extreme care. The RDFI should be aware 
that if a file has been duplicated, the Originator may have 
already generated a reversal transaction to handle the 
situation. 

R29 Corporate Customer Advises Not Authorized 
The RDFI has been notified by the Receiver (non- 
consumer) that a specific transaction has not been 
authorized by the Receiver. 

R31 Permissible Return Entry (CCD and CTX only) 

The RDFI has been notified by the ODFI that the ODFI 
agrees to accept a CCD or CTX return entry in 
accordance with Article Eight, section 8.3 (ODFI Agrees 
to Accept CCD or CTX Return). 

R33 Return of XCK Entry 

The RDFI determines at its sole discretion to return an 
XCK entry. This return reason code may only be used to 
return XCK entries. An XCK entry may be returned up to 
sixty days after its Settlement Date. 

B31 Source Document Presented for Payment 

The source document to which an ARC entry or a POP 
entry relates has been presented for payment. The 
Receiver may request immediate credit from the RDFI for 
an ARC entry or a POP entry for the reason described 
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above. The request must be made in writing within fifteen 
(15) days after the RDFI sends or makes available to the 
Receiver information relating to that debit entry. The 
Receiver must also provide the RDFI with a written 
statement under penalty of perjury that the source 
document was presented for payment. An RDFI using this 
return reason code must transmit the return entry by its 
ACH Operator's deposit deadline for the return entry to 
be made available to the ODFI no later than the opening 
of business on the banking day following the sixtieth 
calendar day following the Settlement Date of the ARC 
entry or the POP entry. 

R38 Stop Payment on Source Document 

The RDFI determines that a stop payment order has been 
placed on the source document to which the ARC entry 
relates. An RDFI using this Return Reason Code must 
transmit the return entry by its ACH Operator's deposit 
deadline for the return entry to be made available to the 
ODFI no later than the opening of business on the banking 
day following the sixtieth calendar day following the 
Settlement Date of the ARC entry to which the source 
document relates. 



Codes to be Used by Federal Government Agencies 
Returning ENR Entries: 

R40 Return of ENR Entry by Federal Government 
Agency (ENR only) 

The Federal Government Agency determines at its sole 
discretion to return an ENR entry. This return reason 
code maybe used only to return ENR entries. 

R41 Invalid Transaction Code (ENR only) 
Either the Transaction Code included in Field 3 of the 
Addenda Record does not conform to the ACH Record 
Format Specifications contained in Appendix Two (ACH 
Record Format Specifications) or it is not appropriate 
with regard to an automated enrollment entry. 

Example: 

Transaction Code "28," Prenotification of Demand Debit 
Authorization, for an ENR sent to Social Security 
Administration pertaining to a direct deposit enrollment. 

R42 Routing Nam ber/Check Digit Error (ENR only) 

The Routing Number and the Check Digit included in 
Field 3 of the Addenda Record is either not a valid 
number or it does not conform to the Modulus 10 formula. 



R43 Invalid DF1 'Account Number (ENR only) 

The consumer's or company's account number included 
in Field 3 of the Addenda Record must include at least 
one alphameric character; 

R44 Invalid Individual ID Number/Identification 
Number (ENR only) 

The Individual ID Number/Identification Number 
provided in Field 3 of the Addenda Record does not 



match a corresponding ID number in the Federal 
Government Agency's records. 

R45 Invalid Individual Name/Company Name (ENR 

only) 

The name of the consumer or company provided in Field 

3 of the Addenda Record either does not match a 

corresponding name in the Federal Government Agency ' s 

records or fails to include at least one alphameric 

character. 

R46 Invalid Representative Payee Indicator (ENR 

only) : ■". 

The Representative Payee Indicator Code included in 

Field 3 of the Addenda Record has been omitted or it is 

not consistent with the Federal Government Agency's 

records. 

Examples: 

The Representative Payee Indicator Code is "zero," and 
Social Security's records indicate that payments should be 
sent to a representative payee on behalf of an entitled 
beneficiary; or 

The Representative Payee Indicator Code is "one," and 
Social Security's records indicate that there is no 
representative payee and the beneficiary may receive 
payments directly. 




R47 Duplicate Enrollment (ENR only) 
The entry is a duplicate of an automated enrollment entry 
previously initiated by a participant in the ENR automated 
enrollment program. 



Codes to be Used for the Return of RCK Entries 
RSO State Law Affecting RCK Acceptance 

* The RDFI is located in a state that has not adopted 
Revised Article 4 of the Uniform Commercial Code 
(1990 Official Text) and has not revised its customer 
agreements to allow for electronic presentment. 

0R 

• The RDFI is located within a state that requires all 
canceled checks to a specific type of account to be 
returned to the Receiver within the periodic statement 

An RCK entry that is returned using this Return Reason 
Code must be transmitted by the RDFI to its ACH 
Operator no later than midnight of the second banking day 
following the banking day of receipt of the presentment 
notice. 
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R51 Item is Ineligible, Notice Not Provided, Signature 
Not Genuine, Item Altered, or Amount of Entry 
Not Accurately Obtained from Item (adjustment 
entries) 

• An RCK entry may be considered to be ineligible if (1) 
the item to which the RCK entry relates is not an item 
within the meaning of Revised Article 4 of the Uniform 
Commercial Code (1990 Official Text); (2) the item is 
not a negotiable demand draft drawn on or payable 
through or at a Participating DFI, other than a Federal 
Reserve Bank or Federal Home LoanBank; (3) the item 
does not contain a pre-printed serial number; (4) the 
item is in an amount of $2,500 or more; (5) the item 
does not indicate on the face of the document that it was 
returned due to "Not Sufficient Funds," "NSF," 
"Uncollected Funds," or comparable language; (6) the 
item is dated more than 1 80 days from the date the entry 
is being transmitted to the RDFI (i.e., the item to which 
the RCK entry relates is stale dated); (7) the item is 
drawn on a non-Consumer Account; or (8) the item has 
been previously presented more than two times in its 
physical form, or more than one time in its physical 
form and more than one time as an RCK entry. 



OR 



The Originator did not provide notice as provided for 
within Article Three, subsection 3.6.2 (Notice 
Obligation). 



OR 



R53 Item and ACH Entry Presented for Payment 
(adjustment entries) 

In addition to an RCK entry, the item to which the RCK 
entry relates has also been presented for payment. The 
Receiver may request immediate credit from the RDFI for 
an RCK entry for the reason described above. The 
request must be made in writing within fifteen (15) days 
after the RDFI sends or makes available to the Receiver 
information relating to that debit entry. The Receiver 
must also provide the RDFI with a written statement under 
penalty of perjury, pursuant to subsection 8.6.5.3 
(Receiver's Written Statement Under Penalty of Perjury 
for RCK Entries), that both the RCK entry and the item to 
which it relates were presented for payment. An RDFI 
using this return reason code must transmit the return 
entry by its ACH Operator's deposit deadline for the 
return entry to be made available to the ODFI no later 
than the opening of business on the banking day following 
the sixtieth calendar day following the Settlement Date of 
the RCK entry. 



Codes to be Used for the Return ofCBR and PER Entries 

R80 Cross-Border Payment Coding Error 

The cross-border entry is being returned due to one or 

more of the following conditions: 

•' invalid Foreign Exchange Indicator; 

■• invalid ISO Originating Currency Code; 

8 invalid ISO Destination Currency Code; 

.• invalid ISO Destination Country Code; or 

• invalid Transaction Type Code. 



All signatures on the item to which the RCK entry 
relates are not authentic or authorized, or the item to 
which the RCK entry relates has been altered. 



OR 



The amount of the RCK entry was not accurately 
obtained from the item. 



R81 Non-Participant in Cross-Border Program 

The cross-border entry is being returned because the 
Originating Gateway Operator does not have an 
agreement with the ODFI to process cross-border entries. 



R82 Invalid Foreign Receiving DFI Identification 

The reference used to identify the Foreign Receiving DFI 
of an outbound cross-border entry is invalid. 



An RDFI using this Return Reason Code must transmit 
the return entry by its ACH Operator's deposit deadline 
for the return entry to be made available to the ODFI no 
later than the opening of business on the banking day 
following the sixtieth calendar day following the 
Settlement Date of the RCK entry to which the item 
relates. 

R52 Stop Payment on Item (adjustment entries) 

The RDFI determines that a stop payment order has been 
placed on the item to which the RCK entry relates. An 
RDFI using this Return Reason Code must transmit the 
return entry by its ACH Operator's deposit deadline for 
the return entry to be made available to the ODFI no later 
than the opening of business on the banking day following 
the sixtieth calendar day following the Settlement Date of 
the RCK entry to which the item relates. 



R83 Foreign Receiving DFI Unable to Settle 

The cross-border entry is being returned due to settlement 
problems in the foreign payment system. 

R84 Entry Not Processed by OGO 

The cross-border entry has not been processed and is 
being returned at the OGO's discretion because the 
processing of such entry may expose the OGO to 
excessive risk. 



Codes to be Used by the ODFIfor Automated Dishonored 
Return Entries ; 

R61. Misrouted Return 

The financial institution preparing the return entry (the 
RDFI of the original entry) has placed the incorrect 
Routing Number in the Receiving DFI Identification field 
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(positions 04-12, including Check Digit, of the Entry 
Detail Record). 

R62 Incorrect Trace Number 

The Trace Number found in positions 07-21 in the 
Addenda Record of the return entry is different from the 
trace number of the original entry. 

R63 Incorrect Dollar Amount 

The dollar amount in the Entry Detail Record of the return 
entry is different from the dollar amount of the original 
entry. 

R64 Incorrect Individual Identification 

The Individual Identification Number reflected in the 
Entry Detail Record of the return entry is different from 
the Individual Identification Number/Identification 
Number used in the original entry. 

R65 Incorrect Transaction Code 

The Transaction Code in the Entry Detail Record of the 
return entry is not the return equivalent of the Transaction 
Code in the original entry. (See list of Transaction Codes 
in Appendix Two (ACH Record Format Specifications). 
All entries must be returned as received: e.g., credit as 
credit, debit as debit, demand as demand, savings as 
savings.) 

R66 Incorrect Company Identification 

The Company Identification number used in the 
Company/Batch Header Record of the return entry is 
different from the Company Identification number used in 
the original entry. 

R67 Duplicate Return 

The ODFI has received more than one return for the same 
entry. 

R68 Untimely Return 

The return entry has not been sent within the timeframe 
established by these rules. 

R69 Multiple Errors 

Two or more of the following fields- Original Entry 
Trace Number, Amount, Individual Identification 
Number/Identification Number, Company Identification, 
and/or Transaction Code » are incorrect. 

R70 Permissible Return Entry Not Accepted 

The ODFI has received a CCD or CTX return entry 
identified by the RDFI as being returned with the 
permission of the ODFI, but the ODFI has not agreed to 
accept the entry. This code may be used only to dishonor 
a return containing an R3 1 return reason code. 



Codes to be used by the RDFI for Automated Contested 
Dishonored Return Entries: 

R71 Misrouted Dishonored Return 

The financial institution preparing the dishonored return 
entry (the ODFI of the original entry) has placed the 
incorrect Routing Number in the Receiving DFI 
Identification field (positions 04-1 2, including Check 
Digit, of the Entry Detail Record). 

R72 Untimely Dishonored Return 

The dishonored return entry has not been sent within the 
designated timeframe. 

R73 Timely Original Return 

The RDFI is certifying that the original return entry was 

sent within the timeframe designated in these rules. 

R74 Corrected Return 

The RDFI is correcting a previous return entry that was 

dishonored because it contained incomplete or incorrect 

information. 

Corrected data will be in its defined position in the 
Company/Batch Header, Entry Detail Record, or Addenda 
Record, as follows: 

■• Original Entry Trace (Dishonored Return Reason Code 
R62) is in the Return Addenda Record, positions 7-21; 

• Dollar amount (Dishonored Return Reason Code R63) 
is in the Entry Detail Record, positions 30-39; 

• Individual Identification Number/Identification Number 
(Dishonored Return Reason Code R64) is in the Entry 
Detail Record, positions 40 - 54 for CCD, POS, PPD, 
and TRC entries, or positions 55 - 76 for CIE and MTE 
entries; 

> Company Identification (Dishonored Return Reason 
Code R66) is in the Company/Batch Header Record, 
positions 41 - 50. 



Codes To Be Used by ACH Operator: (See Appendix 
Three, section 3.6 (Automatic Entry Detail Return Entry) 
for a full explanation of each of these Return Reason 
Codes.) 

my RDFI Not Qualified to Participate 

R18 Improper Effective Entry Date 

R19 Amount Field Error 

R25 Addenda Error 

R26 Mandatory Field Error 

R27 Trace Number Error 

R28 Routing Number Check Digit Error 

R30 RDFI Not Participant in Check Truncation 

Program 
mi RDFI Non-Settlement 
R34 Limited Participation DFI 




OR 95 



APPENDIX FIVE 2005 OPERATING RULES 

R35 Return of Improper Debit Entry 
R36Returnof Improper Credit Entry 



SECTION 5,5 Record Formats for Automated and 
Converted Return Entries 

Unless otherwise noted in the following record formats, 
the field contents for automated and converted return 
entries will match the field contents of the original entries 
[See Appendix Two (ACH Record Format Specifications) 
for the File Header, Company/Batch Control and File 
Control Record formats.] 
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SECTION 5.6 Dishonored ACH Return Entries 

The following specifications apply to Dishonored ACH 
Return Entries: 

• Each Dishonored Return Entry initiated by an ODFI 
must be in the automated format and sequence set forth 
in this Appendix Five. 

• Terms used in the format shall have the meanings set 
forth in Appendix Two (ACH Record Format 
Specifications). 

• The initiation of an Automated Dishonored Return 
Entry with Return Reason Code R68 constitutes a 
certification by the ODFI mat the return was untimely 
and a loss was suffered. 

• The Company/Batch Header Record, Entry Detail 
Record, and Addenda Record format as set forth in this 
Appendix Five must be used. 

• The Transaction Code used in the Entry Detail Record 
must be either 2 1 or 26 for Demand Accounts, 3 1 or 36 
for Savings Accounts, 41 or 46 for General Ledger 
Accounts, or 51 or 56 for Loan Accounts. 

• Addenda Type Code "99" must be used to indicate that 
the addenda record contains automated return 
information. 

• The following fields of the Addenda Record must be 
filled when originating an Automated Dishonored 
Return Entry: 

-- Positions 39 - 53 containing the Return Trace 
Number 

'.— Positions 54 -56 containing the Return Settlement 
'■ Date :' 

- Positions 57 - 58 containing the Return Reason 
' ■ Code' / 
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APPENDIX FIVE 



SECTION 5.7 Contested Dishonored ACH Return 
Entries 

SUBSECTION 5.7.1 Automated Contested Dishonored 
Return Entries 

• Each Automated Contested Dishonored Return Entry 
initiated by an RDFI must be in the format and 
sequence set forth in this Appendix Five. 

• Terms used in the format shall have the meanings set 
forth in Appendix Two (ACH Record Format 
Specifications). 

• The initiation of an Automated Contested Dishonored 
Return Entry constitutes a certification by the RDFI that 
the entry was returned in accordance with these rules. 

• The Company/Batch Header Record, Entry Detail 
Record, and Addenda Record format as set forth in this 
Appendix Five must be used. 

• The Transaction Code used in the Entry Detail Record 
must be either 21 or 26 for Demand Accounts, 31 or 36 
for Savings Accounts, 41 or 46 for General Ledger 
Accounts, or 5 1 or 56 for Loan Accounts. 

• Addenda Type Code "99" must be used to indicate that 
the addenda record contains automated return 
information. 

• The following fields of the Addenda Record must be 
filled when originating an Automated Contested 
Dishonored Return Entry: 



(Company ID), Entry Detail Record (Dollar Amount, 
Individual ID/Identification Number), or Return Addenda 
Record (Original Entry Trace Number). 



Positions 22 
Positions 3 6 
Date) 

Positions 39 
Positions 54 
Positions 57 
Positions 59- 
Positions 74 
Date 
Positions 77 - 



■ 27 Date Original Entry Returned 

• 38 Original Settlement Date (Julian 

■ 53 Return Trace Number 

• 56 Return Settlement Date 

• 58 Return Reason Code 

73 Dishonored Return trace number 
- 76 Dishonored Return Settlement 

78 Dishonored Return Reason Code 



SUBSECTION 5.7.2 Non-Automated Contested 
Dishonored Return Entries 

An ACH Operator that agrees to accept non-automated 
Contested Dishonored ACH Return Entries must convert 
them to an automated format at the point of entry into the 
system. 

SUBSECTION 5.7.3 Corrected Return Entries 

An RDFI may generate a Corrected Return by creating a 
Contested Dishonored Return with reason code "R74." 
The format is the same as that for other Contested 
Dishonored Returns. The corrected data is in its 
prescribed location in the Company/Batch Header Record 




OR 109 



APPENDIX FIVE 



2005 OPERATING RULES 




a 

u 

3 

+*> 

u 
© 
s 
© 



X5 

o 

y 



cS 

■a 

© 

i- 

O 

-S 
<t> 

o 

cs 

. Di 

s 

O 



O 

H 
U 

w 

PQ 



Q 

o 
o 

UJ 
Oi 

OC 
UJ 

a 
< 

UJ 

X 

o 

< 

Z 
< 

a. 

o 
o 



I- 
UJ 

a: 

Q 
UJ 

a: 
o 
z 
o 

X 

w 

Q 

Q 
UJ 

I- 

(0 

UJ 

I- 
z 
o 

O 









CO 






«o 




2 


o 
t» 

. E 

. 3 

z 


t*~ 


c6 
to 




z 




CM 








o o 












z p 




<S 








H < 










cm 


ORIGINA 

DFI 

tDENTIFIC 


2 


i 


oo 


CO 

o 

CO 




0C 




T- 






,- 


INATO 

ATUS 

ODE 


£ 


o 

<D 

E 

03 


■„ 


0) 

m 








< 








O 












H ■ ■ '■ 


l_ 










Z 


>s 










ETTLEME 

DATE 
(JULIAN 


J3 CO 


O 






o 


*0 (U 

is 


(U 

E 
. z 


P 


to 
to 




V) 


< 










UJ 










o» 


uiz< 


a: 


Q 
Q 


to 


lO 
O 




U. uj O 
u. . ■ 




fc 








UJ 












UJ 












>> 




cj 






CO 


OMPAN 

SCRIPT 

DATE 


o 


a) 

E 

CO 


CO 


0> 
CD 






CL 




CD 




O UJ 




< 








o 












z 












>■ o 

1SE 




CD 

E 

TO 

JZ 

a. 




CO 


h- 


OUJ& 


s 


"~ 


'. s 




O UJ 




< 








Q 












UJ 












Q Q 




o 






<o 


STANDAR 

ENTRY 

CLASS CO 


5 


'C 

a> 
E 

CD 

. x: 
a. 
< 


CO 


to 
If) 

in 




z 












O 










»o 


11 


2 


o 

■c 
a) 
E 


o 


o 

5 




OH 




a. 
< 






Q 
























>- 












a: 












>< 




o 








5 z 




'C 






^t 


COMPA 

DISCRETIO 

DATA 


O 


E 

CD 

JZ 

a. 
< 


o 

CM 


o 

2 

CM 




>- 




o 






« 


Q Z 

o 


£ 


0) 

E 

TO 

■ H 
Q. 
< 


CO 


O 
<M 
If) 
O 




UJ 

O " UJ 




O 






CM 


i?38 


2 


a> 

£ 


CO 


O 
CM 




ujo" 




z 




O 




Q 












a: uj uj 








i- 


.■*" 


OQ.O 

o?- o 

UJ t~ O 

0£ 


2 


LO 




o 
o 


















■*-. 












c 










h- 


tt) 










£ 


r- S 


CO 






O 
_l 
UJ 
LL 


ELEME 
NAME 


F/e/d 

Inciusio 

Require 


c 
c 

8 


c: 

0) 


,o 






CO 






DO 



II 



OR J 10 



2005 OPERATING RULES 



APPENDIX FIVE 



T3 






» 






*»» 






s 




Q 

111 


-*«* 




H 


<< 




< 






o 


T3 




H 






3 


& 




< 


<« 




DC 


o 




LU 


!-< 




Q 


u 




K to 


<2 




DQ 9; 


4-> 




■ D 


c* 


'a 


(0 |- 


S 




W UJ 


o 




T3 


'd 


O qj 




» 


** 


O 


© 


oo 


u 


a 

o 


u_ z 
QO 


4) 


Kl 


d: i 


'0 


5 


o£ 


4> 


T3 


OQ 


0) 

0) 






fl 


* fc 


PQ 


© 


UJ CO 


u 


Q UJ 






UJ z 


Q 


1 


I o 


a 

o 




x° 


U 




o 






1- 
< 

CO 


Wj 






O 




' >- 
z 
< 


H 




CL 


U 




2 


W 




o 






O 


P 






Xil 







Si 



: SSij 
SS- : 8 
16° 



.3 Si 



GEE 



ogSS 

— I- K O 












op 

: ils 



?3|8 



u]<< 
cc i o 



138 



AC UJ UJ 

Oig 

o >- o 
uj f- o 



sis 

I- Uj 3 

q m e 



■'.■ § | 

all 

.« b s 



T3 

■ M . 

o 
e 
o 

43 



43 , 



o 



43 



■ « 
w 

6 
3 

<D 

O 

a 
o 

. 43'- 






S3 
O 

U 

a 



1 

<d 

o 



O 

43 



'.&'■■'. £ 



o 

■43 



W 
g 

a 

a> 

. m ■ 
o 
a 
o 

43 

..S3- 

Q 

t» 



a 
o 

a. 

<L> 

3 



I I 



1 I 

: •»■■:. g 

^ -s 

T3 4J 

rS ■'■■"£■ 

U o 

« '•§■ 

00 § 

"£ 60 

■S -S 

60 ^ 



•S -S £ 

:«:■■ -tJ jJ 

(L> <L> cd 

o P o o 

(U -^ <U 0) 

■ 43 ■■« 43 .-g 43 




OR HI 



APPENDIXFIVE 



2005 OPERATING RULES 




a 
u 

o 
.: a 

o 



a 

o 



s 

o 



o 

&* 
O 
u 

o 

■t 

a 

I- 

o 

Pi 
)- 

■o 

g 

O 

H 
U 

W 

CO 

PQ 

CO 



Q 

a: 
o 
o 

UJ 



UJ 

o 

>- 
a: 

H 
Z 

UJ 

UJ 

I- 

$ 

O 

0. 
DC 

o 
o 

■ 

(0 

z 
a: 

.3 
h- 
LU 
DC 

a 

UJ 

o 

z 
o 

X 
(0 

a 

Q 
UJ 

h- 
(0 
UJ 

I- 
z 

o 
o 















*o 


: :M 


'■ 2 


CO 



■c 
<d 

E 

=> 
. z 


if) 




CO 




2 9 S 












7 DC |— 

■ ■ o o o 








en 


CM 


S 


r 


"- 






< * z 








h* 














■'. ' >-'.■■ 












£C 












1 






■e 






^ 


a: Q 

Q 


DC 


0) 

£ 

CO 
< 


CM 


CO 




O 












UJ 












> 




.*: 




to 


o 


DC 
UJ 


:< 

z 


■ c 


CM 


10 




CO 




00 




r-. 




UJ 












a 












© >* ~ ~. 

z£ o P? 




C) 






a» 


RECEIVI 
COMPA 
NAME/I 
NUMBE 


DC 


E 

CO 


(D 


o> 






a. 
< 




10 


CO 


NUMBER OF 
ADDENDA 
RECORDS 


■ ' ■ 2. 


y 

Q) 

■ E 
. z 


*» 


GO 
IT) 

10 




z . 












O 












fc* 




CJ 

■c 








< UJ 




(D 




s 




O CO 




E 






ITS 





ca 









P3 




fc 




-<r 




z z 

UJ 




< 








a 




























**. 








h- 




t*. 






u> 




5 


«o 

8 


O 


O) 

to 

8 


IO 


DFI 
ACCOUNT 
NUMBER 


DC 




. 'C 
0) 

. E 

CO 

a 
< 


r»- 


CM 
CO 








CM 






^r 


O fc 

uj e> 

55 


5 


c 

(U 

E 

■ 3 

z 


.■*- 


CM 
CM 




- Z 




*-.' 








■■■■ -^ 




<; 








5 












zS 




3 




T- 


«o 


ujp 

as 

oca 


5 


1 


CO 


s 




z '■'. 












O 












P ... 




w 








S50 




c 




CO 


M 


2 


i 


CM 


9 

CM 




z 




2 




O 




h- 












Q 












£ UJ UJ 










.*"" ■ 


O >• O 
UJ H O 


2 


SP 


"*" 


O 
O 


















. „ - 












c 










h- 


m 










Z 


e e 


to 






Q 

-J 
UJ 
LL 


l- Ly < 

Q Uj * 


Inclusio 
Require 


1 

3 


C 


■ c 
,9 

to 







? :; : 


6 
3 






a . 


<L> 


■b 




w 


& 


■3 




6 
2 


73 

(D 

O 






s ■■■. 


- O 


O 

a 





7D t-H 




43 

CO 

S- 


r& 




fl CO 


d> 


w 




2 -S 


43 


Q 




43 






w *+3 


c+h .■ ■ : ■ ■ 






^^ 
■ . a : ft 


.P.'- 

M ■ ' 


■a 






:' £ -S 


S , 


^4-H 




O T3 





*T3 




E.i 


3 


0JJ 


.'l.'S 

ft d> 


r 






w .' 


4=1 




s — ^ ■ 







£ 




nv 42 


■£■■■■ 






.-.S-B 


W: 


■i 

: m 




.'■■§ .'.Mil; 
. 'w -S pi 


O 




S3 


73 

(D 


u 

1> 




3 .»{ 


■*-|-' ' 
' O ■ 


1— ( 

■'"e3 




■■&■£ 


d .■■■.' ■ 


43 ■ ■ 

CO 


(L> 

Q 




S'« 


Q 
73 


^ 




CO 


a 




.S3. 40 


■ « 


w 




Q -a 


■'«■■. 


d> 




■ 73 ■ s 


O. . ■■■■. 


-4— » 

cd 




■ p 


O 


O 

& 


^1 


CD 

4^; ■■.:■■ 


O 




^ 


■ W) ■ 


u 




u.§ 


a- 


1 




1^ 


ft . 


<4H 
O 




&jj '2' 


)-!■■■■ 
ft 


T3 




*< 


a 






. 






So 


'43 ■ ■ . . ■ . 

31 . 


r ) 








C3 




1 .§> 


CO 

31 










CO 

■1— < 




3-H 

to a 


(D 


V-1 

W 

e 

■5 






40 

73': ■'■.■.' 
(D ■■.■■■■ 

bO 






S3 J 


CO 
CO 

C3 


T3 




40 rt 


^-i 


^ 




H ° 


CD 




C 
O 

s 

■T3 


*6 


CO 


(90 .0 

§4^ 


1 
1 

CD 
O 


a> 


■> 


■^ O H 


CO 


c 


cu 


CD 


■fl 


<L> 

■43- ■ 


335 ■::■■;■ 





O 


OO 


O " 


{ ) 




*-> >^ 


+-» 




CO 


73 73 


73. 


n 


: <D 


O (L> 


CD . . . 


PL, 


^5 


CJ) &0 

a ■ a 


■s ^ 


iii 


»n'. 


43 43 


43 q . 


H 
O 




u u 


m 


z 


.*-h. (N 


ro'- . ■ .' . : . '■ ■ ■ 



OR 112 



2005 OPERATING RULES 



APPENDIX-FIVE- 



T3 

u 

o 

© 

(ft 

2 



© 



■a 

© 



© 

"3 

P 

a 

© 

H 
U 
W 
en 

n 



Q 
QL 
O 
O 

uj 



m 
Q 

>- 

h- 
Z 
UJ 



w 

q: 

3 
h- 
LU 

oi 

Q 
UJ 

a: 
o 

z 
o 

I 

Q 

uu 
s- 

V) 
UJ 

I- 

z 

o 
o 









CO 






- 


Ujgj 

■v.M 


. . 2 


o 

._ 

£ 

z 


in 


6 

CO 




ago 












^ DC t- 

QUO 








en 


o 


2 


r 


- 






< * Z 








h- 














. _ 












>- 












oc 












< 




o 








z 




■c 






0» 


a: q 
o 
« 
a 


CC 


03 

E 

< 


CM 


CO 




. >- 












5 Q. 












% s 




Q 






CO 


Z ,Oiu 
3 tl> < 


a: 


E 

CD 


CM 
CM 


CO 

to 




Q Z Z 




a. 




tn 




>> 




< 








is 

± UJ 












a: 












££* 












UJ UJ UJ 












£0 CQ CQ 












sss 












_, 3 3 3 












^z z z 




o 








3 Z Z -J 




0) 




■s 


. 


Q O O < 


o 


h 




r " 


>F=i=£ 


J? 




o 




Q < < UJ 




Q. 




"* 




~£ o o « 




< 








— u. u. *: 












FhfJ 












z z "J 












UJ UJ -t 












a a o 




























-t*. 








i- 




t*. 






«D 


z 

■ 3 
O 


:-s 


69 


o 


CO 




s 

< 








CO 


u> 


DFI 
ACCOUNT 
NUMBER 


a; 


O 

E 

Q. 
< 


: n. 


01 
CM 
CO 








CM 






*» 


St 

Ul O 


■ ' ■ 5 


O 

'C 
Q> 

E 
z 


'■;'- 


CM 
.CM 




- z z 




*-;-. 








feo Q 




■ . 






to 


RECEIVING 
IDENTIFICAT 

OGO 
IDENTIFICAT 


5 


j 


CO 


l 




z . 












o 












P,M 




o 








o y 




. 'l_ 




CO 


CM 


«o 


2 


(I) 
£ 


CM 


9 

CM 




z o 








O 




2 












H_ 












■ D 












Of UJ UJ 










■*- 


ECO 
TYP 
COD 


2 


to 


:- 


O 










O 




0£ . . . 


























c 










K 


a> 










■ 2 


c- E 


« 






D 

_j 
LU 
LL 


D4TA 

ELEME 

NAME 


Inclusio 
Require 


§■: 
1: 


Length 
Position 





:v f 


6 

2 


(U 


. ■ ' a 


CD 




w 


C^ 


1 ■ s 

|- ■■■:■■& 


■ ■:t3' ■.■ 

CD 
M 

. o 

T-H O 




*T3 


^H 4=1 . 


b 
p 


o 


1 CO 

35 


QJ 


. ■. a 


CO CD 


^ 


j 


«"4=l 


T3 

2 


C73 

5 


*^3 tw ■ . ■ 


n 


■ O V ' 


a 


.« 


&&'■' 


o 

J3 




•s§ 


s 


. . o 


l-H- 


ftl 


: fe 


.3 ^ - 


•S 


. . Q 


c« r 




O 


A 2 


fa 


■■■': a> 


o ^ 


o 


■ 'S 


■2 ■■&■■■■■■' 


inchanged 
Entry (i.e. 


43 e 


&0 


e 


3 1 na .■ ■ 

O 4J 


-b 


:. a & g 


S 




CD fl : - 

43 ■' Q 


.a 


13 

<D 


^43 




■■■■■.■ M 
■■'''■■ o 


^ Q 


o 
o 


■.■■.-. a 
. o 

■ 43 
.... to 


4^ CD 




.:'■ Q 

<D 


•2"'^ '■'■■ 
30 


o> 


« O 


O 


CO 


•73 <D 


ntry 
onte 


M 43 


W 


o 


tU 

■3 

o 


(D 

■■■■-.■■ '■fl 

.> 
CD 
O 

2 


2 2. 

33 0, 


*o 


U c 


(U 


< .2 


^3 


* 2 
.2 


f ) 




+j . +-» . . 




.■■■■■ a 

■ .s 


bO g 

G -i3 


CD 


... ::3 


; §'^ : :- : . 


■^3 


■43 

CO 


>^ 


e 


':'■'■ : ■'■' .3 
. CD 

■."■'■ 'S 


O 40 

T3 CD 

« '■ SP' ■ 


CD 


o 


a co 


rcJ 


:■:■■;■ ^ 


«j -^ 


(U 




O CD 


O 

o 

CO 

5 


:.v. : : £ 

bo 

:'■"■: ■'. S 

o 


bp g 

43 2 


1> 


■■.{£ O H 


m 


CD 


CD <D 


+-» 


. . : *a 


43 43 


a 


n3 *-* 




o 


<D o 


O O 


( ) 






o 


. *-h CD 


T3 TO. 
CD CD . 


tD GO 


0J3 00 O 




43 43. a 


H 


U U W 


(J 


43 ■■.■■■.■..' 




z 


o ^ 


tN m 




OR 113 



APPENDIX FIVE 



2005 OPERATING RULES 








a 




*^ 




<u 




& 






Q 


u 


£ 


© 

a 


O 


o 


O 


js 


LU 


5 


a: 

< 
a 




z 




UJ 


a 


Q 


o 


Q 


U 


< 


xj 




4> 




S 

o 


CO 

z 
a: 


4=» 


3 


p 
^ 


h- 
LI1 


o 


ft: 


ftS 


Q 




UJ 


o 


a: 


CD 


o 


tf 


Z 


C8 


o 


"d 


X 






< 


Q 


00 


UJ 


r^ 


H 




(0 


.itfi 


LU 


£ 


H 


o 


Z 


H 
U 


o 

o 


(» 




</) 




PQ 


. 


P 


. 


{/) 


■ 





... a 




^ a 








i" w 




■i- 




■* 


to 


"In 


2 


E 


CO 


o 










00 






. z 








Q 












LU 
UJ 




jt 




o> 


^f 


5: 

■ z 


■ c 

TO 


■. - 






Ul 




CD 




h- 












CO 


Q 

ui ' 

zD<n£ 

£S38 

Q 


2 


O 

"C 

d) 
E 

cc 

x: 
a 
< 


CM 


00 


CM 


2 £ 

fcZ UJ 

g££ 2 

« UJ 

5 « 


2 


o 

■c 

CD 

E 

. 3 

z 


<*> 


CO 

4* 




Q 










- 


Igjjl 


'. ^ 


o 
E 


^ 


N. 
C7> 

in 








o 






o 


Z Z 
DCOUJ 
D»D 
h- < O 
UJ ul o 

a or 


2 


0) 

£ 

< 


Csl 


00 

in 




t- 












Z ' ' 
Z UJ 

£ = £ 




o 




to 


o> 


?3S 


2 


E 


ro 






*Ei Q 




3 

z 




in 




w 










(O 


-si 


2 


o 
E 


to 


CO 

m 




^ H=> 




3 




CO 




■ a Z 




z 












CN 








H 










r- 


jZ A 

zE£< 


'■: -s 


o 

■c 
o 
E 


CO 


00 
CO 








3 

z 




CO 




10 












■— z 




<r> 








■ -.*? 




| 




m 




Z Z o 








CO 


«© 


O > IE 

a. uj P 
o o z 

Ul Ul 


cc 


;I 


CO 


CO 
CN 




-*''■ H 




CM n 






in 


ui 5 C z 
h = E a: 
S°z2 


. . . o 


Q 
2 
2 


"5 


CSI 
CN 




■ ° : a 




fc 




CN 
















** >■ w £ 












zaoffl 




0) 


in 


CM 


■ <* 


IMS 


2 


b 

=j 
. z 


o 




UZP.Z 




o 






« 


: .■ '. s 


■ . -t_ 
0) 

E 

a. 
< 


CO 


CD 
9 
S 




3 










Ol 


Its 

■ <.'.■ 


s 


a> 
9 1 


CM 


CO 

o 

CN 
O 




Q 












a uj ui 










T- 


OO.D 

o > o 

Ul K CJ 


... 2 


N- 


o- 












O 


















^_ 












c 










1- 


CD 










S 


c-E 








Q 

-J 


K. Uj S 


o g> 

si* 


■ C ■ 
Cji 




.o 




<t -J <t 




o 




o 


LL 


Q UJ ^ 


X -S * 


o 




0. 



o 

•o 

o 
o 

CD 



t 



^ 



d> 



CD 



o ■ o o 



^^ cn co ^r 



■ OR 114 



2005 OPERA TING RULES 



APPENDIX SIX 



APPENDIX SIX 

OF CHANGE 



NOTIFICATION 



A Notification of Change is created by an RDFI to notify 
the ODFI that previously valid information contained in 
a posted entry has become outdated or that information 
contained in a prenotification is erroneous and should be 
changed. 

A Notification of Change is inapplicable to Shared 
Network Transactions when the RDFI is also the card 
issuer. 



SECTION 6.1 Automated Notification of Chang e 

An Automated Notification of Change must comply with 
the following specifications: 

'•' A zero dollar amount must be indicated 

•Addenda Type Code 98 must be used to indicate that 
the Addenda Record contains automated change 
information. 

• Field 3 . of the Addenda Record must contain the 
appropriate code indicating the information to be 
changed, in accordance with the Table of Change Codes 
set forth in this Appendix Six. Field 7 of the Addenda 
Record must contain the change (correction) 
information corresponding to the change code used, in 
accordance with the Table of Change Codes set forth in 
this Appendix Six. 

• The Standard Entry Class Code "COR" must be used to 
denote a batch containing automated change 
information; 

•: Company/Batch Header Record, Entry Detail Record, 
and Addenda Record formats as set forth in this section 
must be used. 

• The Transaction Code, Entry Detail Record must be 
either 21, 26, 31, 36, 41, 46, 51, or 56. 

SECTION 6.2 Non-Automated Notification of Change 

An ACH Operator that agrees to accept non-automated 
Notification of Change entries must convert them to the 
automated format at the point of entry into the system. 

SECTION 6.3 Refused ACH Notification of Change 

A Refused ACH Notification of Change is created by an 
ODFI to refuse a Notification of Change entry containing 
incorrect or incomplete information. The Refused 
Notification of Change must be in automated form. 



Each automated Refused Notification of Change entry of 
an ODFI must be in the format and sequence set forth in 
this Appendix Six and must contain the reason(s) for the 
refusal of the Notification of Change Entry. 

SECTION 6.4 Minimum Description Standards for 
Notifications of Change and Corrected Notifications of 
Change 

An ODFI must, at a minimum, provide to each of its 
Originators the following information, with respect to 
each Notification of Change or Corrected Notification of 
Change entry received by the ODFI, within two banking 
days of the Settlement Date of the NOC or Corrected 
NOC entry: 

(a) Company Name; 

(b) Company Identification; 

(c) Company Entry Description; 

(d) Effective Entry Date; 

(e) DFI Account Number; 

(f) Individual Name/Receiving Company Name; 

(g) Individual Identification Number/ 
Identification Number; 

(h) Change Code; 

(i) Original Entry Trace Number; 

(j) Original Receiving DFI Identification; and 

(k) Corrected Data. 



SECTION 6.5 Table of Change Codes 

TABLE OF CHANGE CODES 




Code Meaning 



C01 Incorrect DFI Account Number 

Correct DFI Account Number appears in first (left 
justification) 17 positions of the Corrected Data Field. 

CBR, PER: For outbound cross-border entries, the 
correct Foreign Receiver's Account Number will appear 
in the first (left justification) 25 positions of the Corrected 
DataField. 

Example : This code would also be used when an Account 
Number is incorrectly formatted. 



C02 Incorrect Routing Number 

Correct Routing Number (including Check Digit) appears 
in first nine positions of the Corrected Data Field. 

CBR,PBR: For outbound cross-border entries, this field 
refers to the Originating Gateway Operator's routing 
number. 
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Example: Due to merger or consolidation, a once valid 
Routing Number must be changed. 



C03 Incorrect Routing Number and Incorrect DFI 
Account Number " 

Correct Routing Number (including Check Digit) appears 
in first nine positions of the Corrected Data Field-correct 
DFI Account Number appears in the 13 th through 29 th 
position of same field with a space in the 10 th , 1 1 th , and 
12 th position. 

'CBR,- PBR: This change code should not be used for 
outbound cross-border entries due to field length 
limitations. 

Example: Due to merger or consolidation, a once valid 
Routing Number must be changed, and in most instances 
this change will cause a change to the account numbering 
structure. 



C04 Incorrect Individual Name/Receiving Company 
Name 

Correct Individual Name/Receiving Company Name 
appears in first 22 positions of the Corrected Data Field. 



COS Incorrect Transaction Code 

Correct Transaction Code appears in first two positions of 
the Corrected Data Field. 

Example: An item which the RDFI determines should be 
posted to their Demand Deposit Account (DDA) System 
contains a Savings Transaction Code. 



C06 Incorrect DFI Account Number and Incorrect 
Transaction Code 

Correct DFI Account Number appears in the first (left 
justification) 17 positions of the Corrected Data Field « 
correct Transaction Code appears in the 2 1 st and 22 nd 
positions of the same field with spaces in the 1 8 th / 19 th , 
and 20 th positions. 

CBR, PBR : For outbound cross-border entries, the correct 
Foreign Receiver's Account Number appears in the first 
(left justification) 25 positions of the Corrected Data 
Field. The correct Transaction Code appears in the 2 8 l 
and 29 th positions of the same field, with spaces in the 26 th 
and 27 th positions. 

Example: An entry posting to a savings account should 
actually be going to a demand account or vice versa, and 
the account number is also incorrect. 



C07 Incorrect Routing Number, Incorrect DFI 
Account Number, and Incorrect Transaction Code 

Correct Routing Number (including Check Digit) appears 
in the first nine positions of the Corrected Data Field - 
correctDFI Account Number appears in the 10 th through 
26 th positions of the same field ~ and correct Transaction 
Code appears in the 27 th and 28 th positions of the same 
field. 

CBR 9 PBR This change code should not be used for 
outbound cross-border entries due to field length 
limitations. 

Example: An entry posting to a savings account should 
actually be going to a demand account or vice versa, and 
the routing number and account number are also incorrect. 



C08 Incorrect Foreign Receiving DFI Identification 
(CBR and PBR only) 

The correct Foreign Receiving DFI Identification appears 
in the first (left justified) 11 positions of the Corrected 
DataField. 



C09 Incorrect Individual Identification Number 

Correct number appears in first 22 positions of the 
Corrected Data Field. 

Example: Individual's Identification Number within the 
Company is incorrect, either on initial input or through 
merger or consolidation. 



C13 Addenda Format Error 

Information in the Entry Detail Record was correct and 
the entry was able to be processed and posted by the 
RDFI However, iirformation found in the Addenda 
Record was unclear or was formatted incorrectly. 

Example: A CCD entry is received with an "05 "Addenda 
Type Code, but the addenda information does not contain 
payment related ANSI ASC XI 2 data segments or 
NACHA endorsed banking conventions. 
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TABLE OF CHANGE CODES 

FOR REFUSED NOTIFICATION 

OF CHANGE ENTRIES 



Code Meaning 



Change codes C61-C69 are only to be used when refusing 
a Notification of Change: 

C61 Misrouted Notification of Change 

C62 Incorrect Trace Number 

C63 Incorrect Company Identification Number 

C64 Incorrect Individual Identification 
Number/Identification Number 

C65 Incorrectly Formatted Corrected Data 

C66 Incorrect Discretionary Data 

C67 Routing Number Not From Original Entry 
Detail Record 

C68 DFI Account Number Not From Original Entry 
DetailRecord 

C69 Incorrect Transaction Code 



The Refused Notification of Change process can only 
be used with the above Reason Codes (C61 - C69). If 
a reason other than those listed (C61 - C69) exists, the 
item should be handled outside of the Refused 
Notification of Change process. (This limitation 
applies only to the Refused Notification of Change 
process.) 



SECTION 6.6 Record Formats for Automated and 
Converted Notifications of Change 

Unless otherwise noted in the following record formats, 
the field contents for automated and converted 
notifications of change entries will match the field 
contents of the original entries. (See Appendix Two 
(ACH Record Format Specifications) for the File Header, 
Company/Batch Control and File Control Record 
formats.) 
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APPENDIX SEVEN - 
ACKNOWLEDGMENT ENTRIES 



An Acknowledgment Entry is created by an RDFI to 
provide notice to the ODFI that a corporate credit entry 
initiated using a CCD or CTX format has been received 
by the RDFI. 

SECTION 7.1 Acknowledg ment Entries 

An Acknowledgment Entry must comply with the 
following specifications: 

• A zero dollar amount must be indicated. 

• Addenda Type Code "05" is used to indicate that the 
Addenda Record contains acknowledgment 
information. 

.• For an ACK+ or ATX+, Field 3 of the addenda record 
will contain an ANSI ASC X12 REF (Reference) Data 
Segment to acknowledge the receipt by the RDFI of a 
financial EDI credit payment as agreed by the trading 
partners. 

• The Standard Entry Class Code "ACK" or "ATX" must 
be used to denote a batch containing Acknowledgment 
Entries. 

• Company/Batch Header Record, Entry Detail Record, 
and Addenda Record formats as set forth in this section 
must be used. 

• The Transaction Code in the Entry Detail Record must 
be either "24" or "34". 

SECTION 7.2 Refused Acknowledgment Entries 

A Refused Acknowledgment Entry is created by an ODFI 
to refuse an Acknowledgment Entry that is misrouted or 
contains incorrect or incomplete information. Each 
Refused Acknowledgment Entry transmitted by an ODFI 
must be in the format and sequence set forth in this 
Appendix Seven and must contain the reason(s) for the 
refusal of the Acknowledgment Entry. 



SECTION 7.3 Table of Codes for Refused 
Acknowledgment Entries 

TABLE OF CODES 

FOR 

REFUSED ACKNOWLEDGMENT ENTRIES 



Code Meaning 



Codes Al - A3 are only to be used when refusing an 



Acknowledgment Entrv: 

Al Misrouted Acknowledgment Entry 

A2 Incorrect Trace Number 

A3 Incorrect Company Identification Number 

SECTION 7.4 Record Formats for Acknowledgment 
and Refused Acknowledgment Entries 

Unless otherwise noted in the following record formats, 
the field contents for Acknowledgment Entries and 
Refused Acknowledgment Entries will match the field 
contents of the original entries to which the 
Acknowledgments relate. (See Appendix Two, ACH 
Record Format Specifications, for the File Header, 
Company/Batch Control, and File Control Record 
formats.) 
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APPENDIX EIGHT - RULE 

COMPLIANCE AUDIT 
REQUIREMENTS 



This Appendix Eight provides the requirements for an 
audit of compliance with these rules. The intent of these 
provisions is to provide each Participating DFI, and any 
third-party service provider that provides ACH services to 
the Participating DPI, with the specifications for a review 
of its compliance with the ACH rules. Further, the intent 
is, thfcjugh the use of the audit mechanism, to obtain 
compliance with those requirements of these rules that 
have a direct impact on the quality of ACH services and 
the satisfaction of both Participating DFIs and their 
customers; Participating DFIs should be aware that they 
are required to comply with all provisions of these rules; 
however, this Appendix Eight governing audit compliance 
focuses specifically on certain rules provisions that are 
described in Sections 8.2 (Audit Requirements for 
Participating DFIs) and 8.3 (Audit Requirements for 
ODFIs) of this Appendix Eight. 

The following requirements relate solely to compliance 
with ACH rules and, thus, do not cover routine audit 
considerations of financial institution policies and 
procedures that most institutions will also want to review. 
Institutions are also strongly encouraged to review 
government payment regulations as outlined in Title 3 1 
C.F.R. Part 210. 

SECTION 8.1 General Audit Requirements 

Each Participating DFI, and any third-party service 
provider that provides ACH services to the Participating 
DFI, shall, in accordance with standard auditing 
procedures, conduct an internal or external audit of 
compliance with provisions of the ACH rules in 
accordance with the requirements of this Appendix Eight. 
These audit provisions do not prescribe a specific 
methodology to be used for the completion of an audit but 
identify key rule provisions that should be examined 
during the audit process. Such annual audit shall be 
conducted under these Rule Compliance Audit 
Requirements no later than December 1 of each year. This 
audit shall be performed under the direction of the audit 
committee, audit manager, senior level officer, or 
independent (external) examiner or auditor of the 
Participating DFI or third-party service provider. The 
Participating DFI and its third-party service provider must 
retain proof that they have completed an audit of 
compliance in accordance with these rules. 
Documentation supporting the completion of an audit 
must be (1) retained for a period of six years from the date 
of the audit, and (2) provided to the National Association 
upon request. 



SECTION 8.2 Audit Requirements for Participating 

DFIs 

All Participating DFIs, as RDFIs, and their third-party 
service providers shall conduct the following examination 
of ACH operations concerned with receiving ACH 
entries: 

A. Verify that records of entries, including return and 
adjustment entries, transmitted from or to an ACH 
Operator are retained for six years from the date the 
entry was transmitted. Verify that a printout or 
reproduction of the information relating to the entry 
can be provided to the Participating DFTs customer 
or any other Participating DFI or ACH Operator that 
originated, transmitted, or received the entry. 

B. When electronic records are used, verify that such 
records (1) accurately reflect the information 
contained within the record, and (2) are capable of 
being accurately reproduced for later reference, 
whether by transmission, printing, or otherwise. 

C. Verify that prenotifications received are for valid 
accounts and that when a prenotification is not 
processable or is erroneous, the prenotification is 
rejected on a timely basis through the use of return 
entry procedures or that changes are requested 
through the Notification of Change procedure. 

D. Verify that, subject to the RDFI's right of return, all 
types of ACH entries and prenotifications are 
accepted. 

E. Review records and procedures to ensure that funds 
from ACH credit entries are made available to the 
Receiver for withdrawal or cash withdrawal on 
Settlement Date. In the case of PPD credit entries 
made available to the RDFI by 5:00 p.m. local time 
on the banking day prior to the Settlement Date, 
ensure that funds are made available to the Receiver 
for withdrawal or cash withdrawal no later than the 
opening of business on the Settlement Date and that 
debit entries are not posted prior to the Settlement 
Date. 

F. Verify that the RDFI sends or makes available as part 
of the account statement for consumer customers the 
minimum descriptive information concerning each 
credit or debit entry consistent with the requirements 
of Appendix Four (Minimum Description Standards) . 
For ARC, POP, RCK, and XCK entries, also verify 
that the RDFI sends or makes available, as part of the 
account statement for consumers, the contents of the 
Check Serial Number Field with respect to each such 
entry. For POP entries, also verify that the RDFI 
sends or makes available, as part of the account 
statement for consumers, the contents of the Terminal 
City Field and Terminal State Field with respect to 
each such entry. 
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G. For all entries except RCK, review records and 
procedures to determine that returned entries, 
including rejected prenotifications, are received by 
the RDFFsACH Operator by its deposit deadline for M. 
the return entry to be made available to the ODFI no 
later than the opening of business on the second 
banking day following the Settlement Date of the 
original entry. For purposes of the preceding 
sentence, the term second banking day shall refer to 
the second banking day of the RDFI's ACH Operator, 
and the term Settlement Date of the original entry N. 
shall refer to the Settlement Date of the original entry 
that is being returned. Review records and procedures 
to. ensure, that dishonored return entries received by 
the RDFI are handled appropriately, and that 
contested dishonored return entries and corrected 
returns are initiated in a timely manner. 



H, Review internal procedures to ensure that the return 
of an RCK entry is transmitted to the RDFI's ACH 
Operator by midnight of the second banking day 
following the banking day of receipt of the 

presentment notice. 

I. Review internal procedures to ensure that, for each 
RCK entry for which a stop payment has been placed 
on the item to which the RCK entry relates and for 
each ARC entry for which a stop payment order has 
been placed on the source document to which the 
ARC entry relates, the adjustment entry is received 
by the RDFI' s ACH Operator by its deposit deadline 
for the adjustment entry to be made available to the 
ODFI no later than the opening of business on the 
banking day following the sixtieth calendar day 
following the Settlement Date of the original entry. 
(NOTE: No written statement under penalty of 
perjury is required for entries returned for these 
reasons.) 

J. Review records and procedures to ensure that written 
statements under penalty of perjury are obtained from 
consumers for all returns bearing Return Reason 
Codes R07, RIO, R37, R51, and R53, and that each 
adjustment entry is received by the RDFI's ACH 
Operator by its deposit deadline for the adjustment 
entry to he made available to the ODFI no later than 
the opening of business on the banking day following 
the sixtieth calendar day following the Settlement 
Date of the original entry. Verify that copies of 
written statements under penalty of perjury are 
provided to the ODFI within the required time frame, 
when such copies are requested, in writing, by the 
ODFI. 

K. Review internal procedures and customer agreements 
to ensure compliance with UCC Article 4 A with 
respect to ACH transactions. 

L Verify that, with the exception of ■ NOCs due to 
merger or acquisition, Notification of Change entries 
are transmitted within two banking days of the 



0. 



Settlement Date of the entry to which the NOC 

relates. 

Review records and procedures to ensure that, when 
requested to do so by the Receiver, the RDFI 
provides all payment- related information transmitted 
with CCD, CIE, and CTX entries to the Receiver by 
the opening of business on the second banking day 
following the Settlement Date of the entry. 



Review internal procedures to verify that, for 
consumer entries except ARC, POP, RCK, TEL, and 
Single Entry WEB entries, the RDFI has acted on 
stop payment orders placed with the RDFI at least 
three banking days prior to the scheduled date of the 
transfer. For corporate entries, as well as for ARC, 
POP, RCK, TEL, and Single Entry WEB entries, 
verify that the RDFI has acted on stop payment 
orders that have been received in such time and in 
such manner that allow the RDFI to act on the stop 
payment order prior to acting on the debit entry. 

Review internal procedures to ensure that, for each 
entry for which any banking information, including, 
but not limited to, an Entry, Entry Data, a routing 
number, an account number, and a PIN or other 
identification symbol, is transmitted or exchanged 
between a Receiver and an Originator, or an 
Originator and an ODFI, via an Unsecured Electronic 
Network, the Originator, prior to the key entry and 
through transmission of any banking information, ( 1 ) 
encrypts the banking information using a 
commercially reasonable security technology that, at 
a minimum, is equivalent to 128-bit RC4 encryption 
technology, or (2) transmits or receives the banking 
information via a secure session utilizing a 
commercially reasonable security technology that 
provides a level of security that, at a minimum, is 
equivalent to 128-bit RC4 encryption technology. 
[Review internal procedures to ensure that, for each 
en try for wh ich any banking information, including, 
but not limited to, an Entry , Entry Data, a routing 
number, an account number, and a PIN or other 
identification symbol, is transmitted or exchanged 
between an RDFI and an ACH Operator, or an RDFI 
and a Third-Party Service Provider; via an 
Unsecured Electronic Network, the information is (1) 
encrypted using a commercially reasonable security 
technology that, at a minimum, is equivalent to 128- 
bit RC4 encryption technology, or (2) transmitted or 
received via a secure session utilizing a 
commercially reasonable security technology that 
provides a level of security that, at a minimum, is 
equivalent to 128-bit RC4 encryption technology.} 

Transmissions or exchanges of banking information 
over an Unsecured Electronic Network by means of 
voice or keypad inputs from a wireline or wireless 
telephone are not subject to this requirement unless 
the telephone is used to access the Internet. 
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SECTION 8,3 Audit Requirements for QDFIs 

In addition to the examination and control procedures 
outlined in section 8.2 (Audit Requirements for 
Participating DFIs) of this Appendix Eight, ODFIs and 
their third-party service providers shall conduct an 
examination of ACH operations that includes the 
following reviews of procedures relating to the origination 
of ACH entries: 

A. Verify that records of entries, including return and 
adjustment entries, transmitted from or to an ACH 
Operator are retained for six years from the date the 
entry was transmitted. Verify that a printout or 
reproduction of me information relating to the entry 
can be provided to the Participating DFTs customer 
or any other Participating DFI or ACH Operator that 
originated, transmitted, or received the entry. 

B When electronic records are used, verify that such 
records (!) accurately reflect the information 
contained within the record, and (2) are capable of 
being accurately reproduced for later reference, 
whether by transmission, printing, or otherwise. 

$ C. Ensure that agreements have been made with all 
Originators (corporate customers) or Third-Party 
Senders that bind the customer or Third-Party Sender 
to the ACH rules, and that, within such agreements, 
the Originator or Third-Party Sender acknowledges 
that entries may not be initiated that violate the laws 
of the United States. With respect to CBR and PBR 
entries, verify that agreements contain all necessary 
provisions. 

D. Verify that, if applicable, agreements have been made 
with all Sending Points originating transactions on 
behalf of the ODFI. 

E. Review internal procedures and customer agreements 
to ensure compliance with UCC Article 4A with 
respect to ACH transactions. 

♦'.' F. ■ ■ Review internal procedures to determine that 
exposure limits are established for each corporate 
Originator or Third-Party Sender, that these 
procedures provide for the exposure limits to be 
reviewed periodically, and for entries initiated by 
these Originators or Third-Party Senders to be 
monitored relative to the exposure limits across 
multiple settlement dates. 

For CBR and PBR entries, also ensure that the ODFI 
has implemented procedures to monitor the payments 
system risk associated with the initiation of such 
entries by each Originator or Third-Party Sender. 

For WEB entries, also review internal procedures to 
ensure that the ODFI has (1) established procedures 
to monitor the credit- worthiness of each Originator or 
Third-Party Sender on an on-going basis, (2) 
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established an exposure limit for that Originator or 
Third-Party Sender, (3) implemented procedures to 
review that exposure limit periodically, and (4) 
implemented procedures to monitor entries initiated 
by that Originator or Third-Party Sender relative to 
its exposure limit across multiple settlement dates. 

Review internal procedures to ensure that information 
relating to NOCs and Corrected NOCs is provided to 
each Originator or Third-Party Sender within two 
banking days of the Settlement Date of the NOC or 
Corrected NOC in accordance with Appendix Six 
(Notification of Change). 

Review internal procedures to ensure that, when 
agreed to by the ODFI, Permissible Return Entries 
are accepted in accordance with Article Eight, section 
8.3 (ODFI Agrees to Accept CCD or CTX Return). 

Verify that the ODFI has utilized a commercially 
reasonable method to establish the identity of each 
Originator that uses an Unsecured Electronic 
Network to enter into a contractual relationship with 
an ODFI for the origination of ACH transactions. 

Ensure that Originators or Third-Party Senders are 
kept informed of and are in compliance with their 
obligations on a continuing basis, including 
requirements that: 

(1) the Originator obtain the Receiver's 
authorization for entries, and that copies of 
such authorizations are provided to the 
Receiver in accordance with the 
requirements of these rules. 

(2) if Originators choose to initiate 
prenotifications, those prenotifications are 
sent as required by the rules. 

(3) entries returned as "R07 Authorization 
Revoked by Customer", "R08 Payment 
Stopped", or "RIO Customer Advises Not 
Authorized" are not reinitiated unless 
subsequent authorization of their customer 
has been obtained. 

(4) entries returned for RG1 (Insufficient Funds) 
or R09 (Uncollected Funds) are not 
reinitiated in excess of the limits prescribed 
by these rules. 

(5) upon receipt of returns relating to 
prenotifications indicating that the RDFI 
cannot accept such entries, such entries are 
not initiated. 

(6) upon receipt of Notifications of Change, 
requested changes should be made within 
six banking days or prior to the initiation of 
the next entry, whichever is later. 
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(7) 




(8) 



(9) 



(10) 



(11) 



[(12) 



(13): 



(14) 



reversing files and reversing entries are 
transmitted to the Receiving ACH Operator 
in such time as to be transmitted or made 
available to the RDFI within five banking 
days following the Settlement Date of the 
erroneous entry or file. 

Originators initiating POP entries provide 
the Receiver with a receipt that contains 
information relating to the POP entry, as 

required by these rules. 

Originators initiating POP entries void and 
return to the Receiver the source document 
used for the ACH transaction. 

Originators initiating WEB entries have 
employed a commercially reasonable 
fraudulent transaction detection system to 
screen such entries. 

Originators initiating WEB entries have 
used commercially reasonable procedures to 
verify that routing numbers are valid. 

Originators initiating WEB entries have 
employed commercially reasonable 
methods of authentication to verify the 
identity of each Receiver. ] 

Originators initiating WEB entries conduct 
annual audits to ensure that the financial 
information they obtain from Receivers is 
protected by security practices and 
procedures that include, at a minimxirn, 
adequate levels of (1) physical security to 
protect against theft, tampering, or damage, 
(2) personnel and access controls to protect 
against unauthorized access and use, and (3) 
network security to ensure secure capture, 
storage, and distribution. * 



Originators initiating entries for which any 
banking information, including, but not 
limited to, an Entry, Entry Data, a routing 
number, an account number, and a PIN or 
other identification symbol, is transmitted or 
exchanged between a Receiver and an 
Originator, or an Originator and an ODFI, 
via an Unsecured Electronic Network, have, 
prior to the key entry and through 
transmission of any banking information, 

( 1 ) encrypted the banking information using 
a commercially reasonable security 
technology that, at a minimum, is equivalent 
to ■12.8-bit RC4 encryption technology, or 

(2) transmitted or received the banking 
information via a secure session utilizing a 
commercially reasonable security 
technology that provides a level of security 
that, at a minimum, is equivalent to 128-bit 



(15) 



(16) 



RC4 encryption technology. [Originators 
initiating entries for which any banking 
information, including, but not limited to, 
an Entry, Entry Data, a routing number, an 
account number, and a PIN or other 
identification symbol, is transmitted or 
exchanged between a Receiver and an 
Originator, an Originator and an ODFI, or 
an Originator and a Third- Party Service 
Provider, via an Unsecured Electronic 
Network, have, prior to the key entry and 
through transmission of any banking 
information, (J) encrypted the banking 
information using a commercially 
reasonable security technology that, at a 
minimum, is equivalent to 1 2 8- bit RC4 
encryption technology, or (2) transmitted or 
received the banking information via a 
secure session utilizing a commercially 
reasonable security technology that 
provides a level of security that, at a 
minimum, is equivalent to 128-bit RC4 
encryption technology. ] 

Transmissions or exchanges of banking 
information over an Unsecured Electronic 
Network by means of voice or keypad 
inputs from a wireline or wireless telephone 
are not subject to this requirement unless 
the telephone is used to access the Internet. 



for each TEL entry, the Originator (1) has 
employed commercially reasonable 
procedures to verify the identity of the 
Receiver, and (2) has utilized commercially 
reasonable procedures to verify that routing 
numbers are valid. 

for ARC and RCK entries, the Originator 
has provided clear and conspicuous notice 
of the check conversion/truncation policy. 



APPENDIX NINE - 
COMPENSATION RULES 

SECTION 9.1 Scope 

The rules in this Appendix Nine govern the settlement of 
claims for compensation between Participating DFIs. 
These rules apply regardless of the original source or 
ultimate beneficiary of any entry, the manner in which the 
entry was transmitted, or the nature of the transaction to 
which the entry relates. A compensation claim shall be 
paid for an entry only if the loss suffered by the claimant 
is at least $200 per that entry. The amount of loss 
suffered by a claimant shall be calculated using the 
applicable formula provided in this Appendix Nine, 
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excluding the administrative fee of $200 per entry added 
to or subtracted from such formula and adding any 
applicable Deposit Insurance Assessment as described in 
subsection 9.5.2 (Deposit Insurance Assessment) of this 
Appendix Nine. 

SECTION 9.2 Nature of the Rules 

Not every possible scenario concerning a compensation 
claim is explicitly addressed in this Appendix Nine. 
When a meritorious claim for compensation is not 
covered by these rules, Participating DFIs are expected to 
settle the claim so that no Participating DFI is unjustly 
enriched or injured. In general, compensation related to 
a claim must not exceed the benefit that was received by 
the Participating DFI obligated to pay compensation. 
However, compensation may include interest and 
penalties incurred by a Participating DFI as a result of an 
overdraft. Payment or a request for payment of 
compensation under these rules does not constitute and 
shall not be construed as an admission of negligence or 
fault on the part of any Participating DFI involved. 

SECTION 9.3 Manner of Payment 

A compensation payment may be made by an entry or by 
check. Participating DFIs may alter the manner of 
payment of compensation by prior mutual agreement. 

SECTION 9.4 Beneficiaries 

Only Participating DFIs shall have any rights under these 
rules. These rules do not confer any right on any other 
person. 

SECTION 9.5 Definitions 

SUBSECTION 9.5.1 " Federal Funds Rate " 

means the average of each day's Federal Funds Rate for 
the days that a Participating DFI is, under these rules, to 
include in the applicable formula used to calculate 
compensation. The Federal Funds Rate is that rate 
published on a daily basis by the Federal Reserve Bank of 
New York. For any day on which a published rate is not 
available, the Federal Funds Rate is considered to be the 
same as the immediately preceding published rate. 

SUBSECTION 9.5.2 " Deposit Insurance Assessment " 

means either: 



(2) 



in the case of credit unions, the amount of the 
increase, if any, in (a) the amount of deposits 
required to be maintained by the RDFI with the 
NCUSIF (equaling one percent of the total of the 
credit union's insured shares as of the close of the 
preceding insurance year) because the relevant entry 
increased the base upon which the deposits required 
to be maintained will be calculated, and (b) the 
increase, if any, in the deposit insurance premium 
paid or payable by the RDFI to the NCUSIF for that 
insurance year (equaling one-twelfth of one percent 
of the credit union's total insured shares as of the 
close of the preceding insurance year) because the 
relevant entry increased the base upon which the 
insurance premium will be calculated. 



SUBSECTION 9.5.3 




Unless otherwise defined, the terms used in this Appendix 
Nine shall have the meaning ascribed to them in Article 
Fourteen (Definition of Terms). 

SECTION 9.6 Back Valuation 

SUBSECTION 9.6.1 Credit Entries 

( 1 ) An ODFI which transmitted a credit entry may request 
the RDFI to back value the entry. Generally, such request 
is accompanied by a payment for the amount of 
compensation owed pursuant to the formula set forth in 
subsection (2) below. If compensation is paid, the RDFI 
shall back value the payment to the date requested, unless 
one or more of the following conditions exists: (a) the 
Receiver instructs it not to back value such entry; (b) the 
Receivers account has been closed; or (c) the ODFI 
requests a back valuation to a date more than one year 
prior to the effective entry date of the entry. If 
compensation is paid, and the RDFI does not back value 
such entry, the compensation amount shall be promptly 
repaid by the RDFI to the ODFI. (2) If the RDFI back 
values the entry pursuant to the request of the ODFI, the 
ODFI shall pay the RDFI compensation according to the 
following formula (without regard to whether or not the 
Receiver's account was actually in an overdraft position): 



Compensation- 

(Dollar Amount of Entry) (Fed. Funds Rate) 

(No. of Days Back Valued) +$200 



(1) 



the amount of the increase, if any, in an FDIC 
assessment paid or payable by the RDFI because the 
relevant entry increased the base upon which the 
FDIC assessment is calculated. The amount of the 
increase will be calculated using the assessment rate 
adopted by the FDIC for the lowest risk classification 
in its risk-related schedule. 



or 



SECTION 9.7 Forward Valuation 

Credit Entries -- (1) An ODFI which transmitted a credit 
entry may request the RDFI to adjust the payment to a 
future value date. The RDFI is not obligated to make 
such an adjustment. (2) If the RDFI makes the requested 
adjustment, the RDFI shall, upon receiving a claim for 
compensation within 90 days from the date on which such 
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adjustment was made, pay the ODFI compensation 
according to the following formula: 

Compensation = 

(Dollar Amount of Payment) ($200 + 

( 1 00% - Reserve Requirement) Applicable 

(Fed. Funds Rate) Deposit 

(No. of Days Forward Valued) - Insurance 

360 Assessment) 



An RDFI claiming an applicable Deposit Insurance 
Assessment warrants to the ODFI that such amount has 
not been and will not be recovered. If an RDFI adjusts 
the entry pursuant to the ODFI' s request, the RDFI is 
entitled to compensation for the applicable Deposit 
Insurance Assessment even if the ODFI does not claim 
compensation. However, the RDFFs claim for 
compensation must be made within 90 days from the date 
on which the requested adjustment was made. 

If a claim for compensation has been made by the ODFI 
and the compensation is calculated to be zero or a 
negative number, neither the RDFI nor the ODFI shall pay 
any compensation unless a claim for an applicable 
Deposit Insurance Assessment has been made. However, 
if a claim for an applicable Deposit Insurance Assessment 
has been made and the compensation is calculated to be a 
negative number, the ODFI shall pay the RDFI the 
amount of the compensation calculated, i.e., the absolute 
value of the negative number calculated, provided such 
value is $ 1 000 or greater. If a claim for compensation has 
not been made by the ODFI and the RDFI has made a 
claim for an applicable Deposit Insurance Assessment, the 
ODFI shall pay compensation, provided the value of such 
claim is $1000 or greater. 

SECTION 9.8 Return or Reversal of Erroneous Entry 

SUBSECTION 9.8.1 Credit Entries 

(1) If an ODFI has transmitted an erroneous credit entry 
and the RDFI returns the entry pursuant to Article Eight, 
section 8.2 (ODFI Request for Return), or if the entry is 
reversed pursuant to Article Two, section 2.5 (Reversing 
Entries), the RDFI must pay the ODFI compensation 
according to the following formula, upon receipt of a 
claim for compensation within 90 days of the Settlement 
Date of the return or reversal. 



Compensation = 

(Dollar Amount of Erroneous Entry) 
(100% -Reserve Requirement) 

(Fed. Funds Rate) ($200 + 

(No. of Days from Settlement Date of Applicable 

Erroneous Entry to Settlement Date of Deposit 
Return or Reversal — Not to Exceed 1 80) - Insurance 

360 Assessment) 



An RDFI claiming an applicable Deposit Insurance 
Assessment warrants to the ODFI that such amount has 
not been and will not be recovered. If an RDFI adjusts 
the entry pursuant to the ODFI's request, the RDFI is 
entitled to compensation for the applicable Deposit 
Insurance Assessment even if the ODFI does not claim 
compensation. However, the RDFI's claim for 
compensation must be made within 90 days from the date 
on which the requested adjustment was made. 

If a claim for compensation has been made by the ODFI 
and the compensation is calculated to be zero or a 
negative number, neither the RDFI nor the ODFI shall pay 
any compensation unless a claim for an applicable 
Deposit Insurance Assessment has been made. However, 
if a claim for an applicable Deposit Insurance Assessment 
has been made and the compensation is calculated to be a 
negative number, the ODFI shall pay the RDFI the 
amount of the compensation calculated, i.e., the absolute 
value of the negative number calculated, provided such 
value is $ 1 000 or greater. If a claim for compensation has 
not been made by the ODFI and the RDFI has made a 
claim for an applicable Deposit Insurance Assessment, the 
ODFI shall pay compensation, provided the value of such 
claim is $ 1 000 or greater. 

(2) If a missent credit entry is retained by the RDFI for 
more than 180 days, the Fed. Funds Rate means the Fed. 
Funds Rate in effect during the most recent 1 80 day time 
period. 

SUBSECTION 9.8.2 Debit Entries 

(1) If an ODFI has transmitted an erroneous debit entry 
and the RDFI returns the entry pursuant to Article Eight, 
section 8.2 (ODFI Request for Return), the ODFI must 
pay the RDFI compensation upon its request according to 
me following formula: 

Compensation = 

(Dollar Amount of Erroneous Entry) 

(Fed. FundsRate) ($200 + 

(No. of Days from Settlement Date of Applicable 

Erroneous Entry to Settlement Date of Deposit 

Return or Reversal - Not to Exceed 180) + Insurance 
360 Assessment) 
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(2) If a missent debit entry is retained by the RDFI for 
more than 1 80 days, the Fed. Funds Rate means the Fed. 
Funds Rate in effect during the most recent 1 80 day time 
period. 

SECTION 9.9 Change of Beneficiary 

SUBSECTION 9.9.1 Credit Entries 

If an ODFI has transmitted a credit entry to the correct 
RDFI but the entry was to the wrong account or omitted 
account information, and the RDFI adjusts the entry at the 
request of the ODFI pursuant to Article Eight, section 8.2 
(ODFI Request for Return), the ODFI must pay the RDFI 
compensation according to the following formula, 
provided that a request for back valuation is made within 
180 days of the effective entry date of the entry. This 
section applies whether or not the beneficiary's account 
was actually in an overdraft position. 

Compensation - 

(Dollar Amount of Entry) 
(Reserve Requirement) 
(Fed. Funds Rate) 
(No. of Days from Receipt to 
Adjustment - Not to Exceed 180) + $200 
360 



NOTE: For purposes of this rule, "No. of Days" means a period no 
longer than 2 business days beyond the date on which an Indemnity is 
received. 

SUBSECTION 9.9.2 Debit Entries 



If an ODFI has transmitted a debit entry to the correct 
RDFI but the entry was to the wrong account or omitted 
account information, and the RDFI adjusts the entry at the 
request of the ODFI pursuant to Article Eight, section 8.2 
(ODFI Request for Return), the ODFI must pay the RDFI 
compensation according to the following formula, 
provided that a request for back valuation is made within 
180 days from the effective entry date of the entry. 

Compensation = 

(Dollar Amount of Entry) 

(Reserve Requirement) 

(Fed. Funds Rate) 

(No. of Days from Receipt to 

Adjustment - Not to Exceed 180V + $200 

360 



APPENDIX TEN 
PROCEDURES 

SECTION 10 ♦! Scope 



ARBITRATION 



The rules contained in this Appendix Ten govern the 
settlement of disputes arising under these rules between 
Participating DFIs by arbitration. In the event of any 
inconsistency between the provisions of this Appendix 
and of Articles One through Eleven of these rules, the 
provisions of this Appendix Ten shall control. An 
arbitration claim under this Appendix Ten shall be 
processed only if the amount of the damages claimed is 
$250ormore. 

SECTION 10.2 Filing a Complaint 

To initiate an arbitration proceeding, a Participating DFI 
(the "complainant") shall submit a complaint to the 
National Association. A complaint shall contain the 
following: 

SUBSECTION 10.2.1 Identification of Parties 

The names, addresses and telephone numbers of the 
complainant and the other party involved in the dispute 
(the "respondent"). 

SUBSECTION 10.2.2 Summary of Facts 

A summary of the facts of the dispute as well as the 
section(s) of the rules that is/are alleged to have been 
violated. The summary shall also include information 
permitting identification of the particular transaction(s) 
and the sequence of events involved, and the precise 
nature of the violation(s). 

SUBSECTION 10.2.3 Statement of Damages 

A statement of the dollar amount of damages claimed by 
the complainant and an explanation of how damages in the 
amount claimed resulted from the violation(s) asserted. 

SUBSECTION 10.2.4 Additional Documents and Fees 




The complaint shall be accompanied by the following: 
SUBSECTION 10.2.4.1 Documents Relating to Claim 



NOTE: For purposes of this rule, "No. of Days" means a period no 
longer than 2 business days beyond the date on which an Indemnity is 
received. 



Copies of the documents available to the complainant 
necessary to resolve the dispute, and of any written 
communications by the complainant and the respondent 
relating to the violations) asserted. 
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SUBSECTION 10.2.4.2 Application Fee 

A $250 non-refundable application fee to be used for 
administrative expenses. 



SUBSECTION 10.2.5 
Complaint 



Authorization for Submitting a 




The complaint shall be signed by an officer of the 
complainant and be submitted to the National Association 
within two (2) years of the violations asserted. 

SUBSECTION 10.2.6 Complaints Involving Multiple 
Participating DFIs 

If the complainant is involved in related disputes with 
more than one Participating DFI, a separate complaint 
shall be filed with respect to each such Participating DFI. 

SECTION 10.3 Classification of Disputes 

SUBSECTION 1 0.3. 1 Complaints with Damages of $250 
or More But Less Than $ 10,000 (Arbitration Procedure 

a) ■■■■■■■-■;■;■:■■■.;. 

All complaints in which the amount of damages claimed 
is $250 or more but less than $10,000 shall be processed 
under Arbitration Procedure A set forth in these rules. 
Under Arbitration Procedure A: (1) Arbitration is 
mandatory for both parties once a claim for arbitration is 
filed in accordance with these rules; (2) A hearing shall 
not be held; (3) One arbitrator shall decide the case; and 
(4) The arbitrator's stipend shall be $100. 

SUBSECTION 10.3.2 Complaints with Damages of 
$10,000 or More But Less Than $50.000 (Arbitration 
Procedure B) 

All complaints in which the amount of damages claimed 
is $10,000 or more but less than $50,000 shall be 
processed under Arbitration Procedure B set forth in these 
rules. Under Arbitration Procedure B: (1) Arbitration is 
mandatory for both parties once a claim for arbitration is 
filed in accordance with these rules; (2) A hearing shall 
not be held; (3) Three arbitrators shall decide the case; 
and (4) The stipend for each arbitrator shall be 1% of the 
arbitrator's decision. 

SI JBSECTION 10.3.3 Complaints with Damages of 
$50,000 or More (Arbitration Procedure C) 

All complaints in which the amount of damages claimed 
is $50,000 or more shall be processed under Arbitration 
Procedure C set forth in these rules. Under Arbitration 
Procedure C: ( 1 ) Arbitration is not mandatory. Before the 
complaint is filed, both parties must agree to submit the 
dispute to arbitration. If both parties so agree, one of 
them shall submit to the National Association a complaint 
that complies with these rules; (2) A hearing shall be held 
unless the parties otherwise agree and so notify the 
National Association at the time the complaint is filed. If 



the parties do so otherwise agree, the procedures set forth 
in subsection 1 0,5 .2 (Arbitration Procedure B) rather than 
subsection 1 0.5.3 (Arbitration Procedure C) of this 
Appendix Ten shall be followed; (3) At its discretion, a 
party may be represented at the hearing by legal counsel; 
(4) Three arbitrators shall decide the case; and (5) The 
stipend for each arbitrator shall be 1 .5% of the arbitrator's 
decision. 

SECTION 10.4 Selection of Arbitrators 

The National Association shall maintain a list of 
arbitrators that have been nominated by Associations in 
accordance with the procedures established by the 
National Association. 

SUBSECTION 1 0.4. 1 Arbitration Procedure A 

For claims subject to Arbitration Procedure A, an 
arbitrator will be selected by the following method: (1) 
The National Association shall mail each party the same 
list of five arbitrators from among those nominated as 
provided herein who are not affiliated with either party to 
the dispute; (2) Each party shall be given ten days from 
the date the list is mailed to review the list, delete two 
names, and mail or deliver the remaining names to the 
National Association; (3) The National Association shall 
then compare the two lists and select one arbitrator not 
deleted from either list to decide the case; and (4) If either 
list is not returned within the time limit specified above, 
the National Association shall then select the arbitrator to 
decide the case from among the names not deleted on the 
list returned, or, if neither list is returned within the time 
limit, from among the names on the lists as mailed to each 
party. 

SUBSECTION 10.4.2 Arbitration Procedures B and C 

For claims subject to Arbitration Procedures B and C, 
arbitrators will be selected by the following method: (1) 
The National Association shall mail each party the same 
list of ten arbitrators from among those nominated as 
provided herein who are not affiliated with either party to 
the dispute; (2) Each party will have ten days from the 
date the list is mailed to review the list, delete three 
names, and mail or deliver the remaining names to the 
National Association; (3) The National Association shall 
then compare the two lists and select three arbitrators not 
deleted from either list to decide the case; and (4) If 
either list is not returned within the time limit specified 
above, the National Association shall then select the 
arbitrators to decide the case from among the names not 
deleted on the list returned, or, if neither list is returned 
within that time limit, from among the names on the list as 
mailed to each party. 
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SECTION 10.5 Presentation of the Case and the 
Decision 

SUBSECTION 10.5.1 Arbitration Procedure A 

Cases subject to Arbitration Procedure A will be 
presented and the decisions reached according to the 
following requirements: (1) After a party has received 
notification of the selection of the arbitrator, it will have 
fourteen (14) days to submit to the National Association 
in writing for consideration in such proceeding any matter 
it deems appropriate, and the National Association shall 
submit copies of such materials to the arbitrator and the 
other party; (2) In the event the respondent, in the 
judgment of the arbitrator, fails to cooperate in the 
proceeding within fourteen (14) days of a request for 
information by the arbitrator, the facts as stated in the 
complaint shall be assumed to be true for purposes of the 
arbitration; (3) Once the arbitrator has received all 
information he or she deems relevant or necessary, the 
arbitrator shall have thirty (30) days to render his or her 
decision/The amount of the award of damages may not 
exceed the amount of damages claimed in the complaint; 
(4) The arbitrator may adopt such rules and procedures 
with respect to evidence and other procedural and 
substantive matters not inconsistent with these rules as he 
or she may deem appropriate; (5) The decision of the 
arbitrator shall be based upon the rules insofar as they are 
applicable; (6) Neither party shall initiate contact with the 
arbitrator concerning the subject matter of the dispute 
unless the other party is present; (7) The arbitrator shall 
be entitled to recover a part or all of the arbitrator's 
stipend from either party as determined by the arbitrator; 
and (8) The arbitrator shall pay his or her expenses and 
each party shall pay its own expenses, including attorneys' 
fees, in connection with the arbitration. 



SUBSECTION 10.5.2 Arbitration Procedure B 

Cases subject to Arbitration Procedure B will be 
presented and the decisions reached according to the 
following requirements: (1 ) After a party has received 
notification of the selection of the arbitrators, it will have 
fourteen (14) days to submit to the National Association 
in writing for consideration in such proceeding any matter 
it deems appropriate, and the National Association shall 
submit copies of such materials to the arbitrators and the 
other party; (2) In the event the respondent, in the 
judgment of the arbitrators, fails to cooperate in the 
proceeding within fourteen (14) days of a request for 
information by the arbitrators, the facts as stated in the 
complaint shall be assumed to be true for purposes of the 
arbitration; (3) Once the arbitrators have received all 
information they deem relevant or necessary, the 
arbitrators shall have thirty (30) days to render their 
decision. The amount of the award of damages may not 
exceed the amount of damages claimed in the complaint; 
(4) The arbitrators may adopt such rules and procedures 
with respect to evidence and other procedural and 
substantive matters not inconsistent with these rules as 
they may deem appropriate; (5) The decision of the 



arbitrators shall be based upon the rules insofar as they are 
applicable; (6) Neither party shall initiate contact with the 
arbitrators concerning the subject matter of the dispute 
unless the other party is present; (7) The arbitrators shall 
be entitled to recover a part or all of the arbitrators' 
stipend from either party as determined by the arbitrators; 
and (8) The arbitrators shall pay their expenses and each 
party shall pay its own expenses, including attorneys ' fees, 
in connection with the arbitration. 

SUBSECTION 10.5.3 Arbitration Procedure C 

Cases subject to Arbitration Procedure C will be 
presented and the decisions reached according to the 
following requirements: (1) If a hearing is to be held, the 
arbitrators shall set a hearing date which shall not be less 
than ninety (90) days after each party has received 
notification of the selection of the arbitrators; (2) The 
National Association shall provide both parties with at 
least thirty (30) days prior notice of the hearing; (3) 
Following the hearing, the arbitrators shall have thirty 
(30) days to render their decision. The amount of the 
award of damages may not exceed the amount of damages 
claimed in the complaint; (4) The arbitrators may adopt 
such rules and procedures with respect to evidence and 
other procedural and substantive matters not inconsistent 
with these rules as they may deem appropriate; (5) The 
decision of the arbitrators shall be based upon the rules 
insofar as they are applicable; (6) Neither party shall 
initiate contact with any arbitrator concerning the subject 
matter of the dispute unless the other party is present; (7) 
Each party shall pay its own expenses, including attorneys' 
fees, in connection with the arbitration; and (8) The 
arbitrators shall be entitled to recover a part or all of their 
travel and other expenses in connection with the 
arbitration and the arbitrators' stipend from either party, as 
determined by the arbitrators. 

SECTION 10.6 Payment and Appeal 

SUBSECTION 1 0.6. 1 Arbitration Procedures A and B 

Payments of awards and appeals of decisions will be 
subject to the following requirements: ( 1 ) The party 
against which such amount has been assessed shall have 
fourteen ( 1 4) days after receiving notice of the decision in 
which to pay the damage award or other amount assessed 
against it as provided in these rules; (2) The decision of 
the arbitrator(s) shall be final and binding on the parties to 
the dispute, and judgment thereon may be entered in any 
court having jurisdiction. Except to the extent such a 
prohibition is unlawful under the laws of the state in 
which the party against which damages have been 
awarded by the arbitrator(s) is domiciled, such decision 
shall not be appealable to the courts. 

SUBSECTION 10.6.2 Arbitration Procedure C 




Payments of awards and appeals of decisions will be 
subject to the following requirements: (1) In the absence 
of an appeal to the courts, the party against which such 
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amount has been assessed shall have fourteen (14) days 
after receiving notice of the decision in which to pay the 
damage award or other amount assessed against it as 
provided in these rules; (2) The arbitrators' decision shall 
be binding on the parties to the dispute, and judgment 
thereon may be entered by any court having jurisdiction. 
Except to the extent the parties have entered into an 
enforceable agreement to the contrary, either party may 
appeal the arbitrators' decision to the courts. In the 
absence of such an appeal, the arbitrators' decision shall 
be final 




APPENDIX ELEVEN - THE 
NATIONAL SYSTEM OF FINES 

SECTION ILl Scope 

Appendix Eleven governs the rules enforcement 
procedures to be applied in the event of a possible ACH 
rules violation that is the responsibility of the 
Participating DFI. It is the intent of this enforcement 
mechanism to maintain the quality of ACH services and 
the satisfaction of Participating DFIs and their customers 
by ensuring compliance by Participating DFIs with these 
rules through the National System of Fines. 

SECTION 11.2 Reporting of Rules Violations : 

A rules enforcement proceeding may be initiated for any 
violation of these rules. To initiate a rules enforcement 
proceeding, a Participating DFI or other ACH participant 
(the "complainant") shall submit a Report of Possible 
ACH Rules Violation to the National Association. The 
complainant must be a party to the transaction. This form 
and filing instructions are located within Section IV, 
Chapter IV (Rules Enforcement) of the NACHA 
Operating Guidelines. This Report concerning an ACH 
rules violation shall contain the following: 

SUBSECTION 1 1 .2.1 Identification of Parties 

The names, addresses, and telephone numbers of the 
complainant and the other party involved in the dispute 
(the "respondent") and routing number of the respondent; 

SUBSECTION 11.2.2 Siuiimarv of Facts 

A summary of the facts of the alleged rule violation, as 
well as the section(s) of the rules violated. The summary 
shall also include information permitting identification of 
the particular transaction(s), the sequence of events 
involved, the precise nature of the violations), and the 
consequences to the complainant. 



SUBSECTION 1 1 .2.3 Documents Relating to Possible 
Rules Violation 

Copies of the documents available to the complainant 
necessary to support the claim that an ACH rule has been 
violated, and of any written communications by the 
complainant and the respondent relating to the violation(s) 
asserted. 

SUBSECTION 1 1.2.4 Authorization for Submitting a 
Rules Violation Report 

The Report of Possible ACH Rules Violation shall be 
signed by an officer of the complainant and be submitted 
to the National Association within ninety (90) days of the 
occurrence of the rule violation(s) asserted. 

SUBSECTION 11.2.5 Complaints Involving Multiple 
Participating DFIs 

If the complainant is asserting rules violations against 
more than one Participating DFI, a separate Report of 
Possible ACH Rules Violation shall be filed with respect 
to each such Participating DFI. 

SUBSECTION 1 1 .2.6 Resolution of Complaint 

The National Association will notify the complainant 
upon the resolution of the alleged rule violation that either 
(1) the violation has been resolved or will be within a 
certain time period, or (2) that the respondent has refuted 
the claim of a rules violation. 

SECTION 11.3 National Association and Respondent 
Financial Institution Action on Report of Possible 
ACH Rules Violation 

SUBSECTION 1 1.3.1 Notice of Possible ACH Rules 
Violation 

Each Report of Possible ACH Rules Violation submitted 
to the National Association will be reviewed to ensure that 
the minimum documentation necessary to identify the 
incident has been included and to ascertain whether a 
violation of these rules has occurred. An informational 
copy of the report will be forwarded to the regional ACH 
Association of both the complainant and the respondent. 
If either party is an access participant (i.e., not a member 
of a regional ACH association), an informational copy 
will be forwarded to the local Federal Reserve Bank. 

If the National Association makes a preliminary 
determination that a violation of these rules has occurred, 
a Notice of Possible ACH Rules Violation will be sent to 
the ACH Manager at the respondent financial institution, 
within five banking days via traceable delivery method, 
indicating that an infraction of the rules appears to have 
occurred and explaining that fines may be imposed against 
the financial institution in the event that the rule violation 
is not corrected. The financial institution will be asked to 
correct the problem that caused the rule violation and to 
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respond within fifteen banking days of the date on which 
it received the Notice of Possible ACH Rules Violation. 
The Notice of Possible AGH Rules Violation Response 
Form must be sent, via traceable delivery method, to the 
National Association with either (1) an acknowledgment 
of the financial institution's recognition of and intent to 
correct the problem, along with a statement specifying the 
date by which the financial institution will resolve the 
problem (Resolution Date), or (2) a statement that the 
financial institution does not believe that a rules infraction 
has occurred. 

If the National Association receives, within the 
appropriate time frame, a Notice of Possible AGH Rules 
Violation Response Form from the financial institution 
indicating that (1) the financial institution acknowledges 
and will correct the problem causing the rules violation, 
or (2) appropriate documentation is attached that refutes 
the claim of a rules violation, no additional action will be 
taken by the National Association at that time. If the 
National Association receives no response from the 
financial institution, a Notice of Possible Fine will be sent 
to the financial institution in accordance with subsection 
1 1 .3.2 (Notice of Possible Fine) of this Appendix Eleven 
and the National Association will forward the issue to the 
ACH Rules Enforcement Panel to consider the imposition 
of a fine against the financial institution in accordance 
with Section 1 1.5 (Fines) of this Appendix Eleven. If the 
National Association believes the time frame and 
Resolution Date asserted by a financial institution as 
necessary to resolve the problem causing the rules 
violation is excessive, or if the National Association 
believes the violation significantly harms other financial 
institutions, it may forward the issue to the ACH Rules 
Enforcement Panel for additional review, and the Panel 
will consider the imposition of a fine against the financial 
institution in accordance with Section 1 1.5 (Fines) of this 
Appendix Eleven. If the National Association determines 
that it is unclear whether a rules violation has, indeed, 
occurred, it may forward the issue to the ACH Rules 
Enforcement Panel for additional review. 

SUBSECTION 11.3.2 Notice of Possible Fine 

If a financial institution (1) is cited with the recurrence of 
a rules violation for which a Notice of Possible ACH 
Rules Violation has been sent by the National 
Association, or (2) fails to submit a Notice of Possible 
ACH Rules Violation Response Form to the National 
Association, a Notice of Possible Fine will be sent to both 
the ACH Manager and the Chief Operating Officer at the 
financial institution via traceable delivery method 
indicating that this issue will be forwarded to the ACH 
Rules Enforcement Panel for review and the Panel will 
consider the imposition of a fine against the financial 
institution in accordance with Section 1 1 .5 (Fines) of this 
Appendix Eleven. The financial institution will be asked 
for the second time to correct the problem that caused the 
rule violation and to respond within ten banking days of 
the date on which it received a Notice of Possible Fine. 
The Notice of Possible Fine Response Formmust be sent, 



via traceable delivery method, to the National Association 
with either (1) an acknowledgment of the financial 
institution's recognition of and intent to correct the 
problem, along with a .statement specifying the Resolution 
Date, or (2) a statement that the financial institution does 
not believe that a rules violation occurred. 

If the National Association receives, within the 
appropriate time frame, a Notice of Possible Fine 
Response Form from the financial institution refuting the 
claimof a rules violation with appropriate documentation, 
no additional action will be taken by the National 
Association at that time. Otherwise, the National 
Association will forward the issue to the ACH Rules 
Enforcement Panel for its consideration. 

SECTION 11.4. ACH Rules Enforcement Panel 

SUBSECTION 1 1 .4.1 Selection of Enforcement Panel 

The National Association shall maintain a list of members 
of the ACH Rules Enforcement Panel that have been 
nominated in accordance with the procedures established 
by the National Association. 

SUBSECTION 1 1.4.2 Responsibilities of Enforcement 
Panel 

The ACH Rules Enforcement Panel, in accordance with 
these rules, is the final authority regarding each of these 
issues: 

•■ the imposition of any fines recommended by the 
National Association; 

® instances in which the National Association believes the 
time frames and Resolution Dates asserted by the 
respondent financial institution as necessary to resolve 
the problem causing a rules violation are excessive; 

•'■ rules violations that the National Association believes 
significantly harm other financial institutions; and 

• situations in which the National Association determines 
that it is unclear whether a rules violation has occurred. 

SECTION 11.5 Fines - ' : ^- ^ ■■■■■; ^'■■\: : ; : 
SUBSECTION 11.5.1 Imposition of Fines 




In the event that a financial institution (1) fails to correct 
a problem causing a rules violation after receiving a 
Notice of Possible ACH Rules Violation, or (2) fails to 
respond to a Notice of Possible ACH Rules Violation, the 
National Association will impose a fine, subject to 
approval by the ACH Rules Enforcement Panel, on the 
financial institution in accordance with section 1 1 .5.3 
(Amount of Fine and Recurrence of ACH Rules 
Violations) of this Appendix Eleven, The National 
Association will collect a fine by transmitting an ACH 
debit to the account of the affected financial institution 
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(respondent). Each Participating DFI agrees to the 
payment of any fines in accordance with this process. The 
National Association will provide notice to the financial 
institution (respondent) of the date and amount of the 
debit at least seven banking days in advance of the 
Settlement Date of the debit. 

SUBSECTION 1 1.5.2 Determination of Fines 

The fine(s) levied against a respondent financial 
institution for an infraction(s) of these rules will be 
determined based on an evaluation by the National 
Association of whether the rules violation is a recurrence 
of a problem previously acknowledged by the respondent 
financial institution or whether the rules violation has 
continued to occur due to the willful disregard by the 
respondent of the problem causing the rules violation. 



rules violation are excessive; (4) the ACH Rules 
Enforcement Panel believes that the violation significantly 
harms other financial institutions; (5) it is the fourth 
recurrence of the same rules violation, or (6) the ODFI 
has failed to provide reporting information for 
unauthorized TEL entries in accordance with the 
requirements of subsection 2.1 1.3 (TEL Entry Reporting 
Requirements). 



SUBSECTION 1 1 .5.3 Amount of Fine and Recurrence of 
ACH Rules Violation 



A rules violation is considered to be a recurrence of a 
previously reported infraction of these rules if: 

• the same infraction is committed by the same Originator 
that transmits through the ODFI within the one year 
period following the Resolution Date of the initial rules 
violation; 

• the same infraction is committed by the same Third- 
Party Service Provider transmitting through or on 
behalf of an ODFI or receiving on behalf of an RDFI 
within the one year period following the Resolution 
Date of the initial rules violation; or 

» the same infraction is committed by the same financial 
institution within the one year period following the 
Resolution Date of the initial rules violation. 



The first recurrence of a rules violation that will cause a 
fine to be levied by the National Association will result in 
an assessment of $250 against the financial institution. 
The second recurrence of a rules violation that causes a 
fine to be levied by the National Association will result in 
an assessment of $750 against the financial institution. 
The third recurrence of a rules violation that causes a fine 
to be levied by the National Association will result in an 
assessment of $ 1 ,500 against the financial institution. The 
fine levied against a financial institution for the willful 
disregard of an ACH rules violation will be in the amount 
of $ 1 0, 000 per month until the problem is resolved. 

A rules violation that has occurred due to the willful 
disregard by the respondent is one in which ( 1 ) the 
financial institution has not responded to either the Notice 
of Possible ACH Rules Violation or the Notice of 
Possible Fine, (2) the financial institution responds to 
either notice that it does not intend to correct the rules 
violation, (3) the ACH Rules Enforcement Panel believes 
the time frame and Resolution Date asserted by a financial 
institution as necessary to resolve the problem causing the 
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Acceptance of adjustment entries, OR 26 
Acceptance of return entries, OR 19 
Account closed code, OR 90 
Account frozen code, OR 92 
Account holder deceased code, OR 92 
Account numbers 

posting entries, OR 16 

returned entries, OR 20 
Account sold to another DFI code, OR 92 
Accountability for entries, OR 21 
Accounting information, automated, OR 27 
Accounts receivable entries 

defined, OR33 

format specifications, OR 82 

notification, OR 3 

obligations of originators, OR 14 

origination of, OR 10-OR 11 

receiver's right to recredit, OR 22-OR 23 

receiver's written statement, OR 24 

right to adjustment, OR 26 

sequence of records, OR 49 
Accredited Standards Cornmittee 

application control structure, OR 33 

interchange control structure, OR 33 

PIN requirements, OR 5, OR 12 
Accurate reflection of item, OR 8, OR 9 
ACH. See Automated Clearing House 
ACH Operators. See Automated Clearing House Operators 
ACK entries. See Acknowledgment entries 
Acknowledgment entries 
■defined, OR' 33'' 

format specifications, OR 82, OR 128-OR 134 

general rule, OR 21 

refused, OR 21, OR 128, OR 132-OR 133 

technical specifications, OR 128-OR 1 34 
Addenda information, OR 70 
Addenda records 

contested dishonored returns, OR 1 14 

dishonored returns, OR 108 

indicators, OR 68, OR 70 

notifications of change, OR 122 

refused notifications of change, OR 127 

return records, OR 10 1-OR 102 

specifications, OR 39, OR 50-OR 57, OR 59-OR 60, OR 62, OR 65-OR 66, OR 1 30, OR 1 3 1 
Addenda sequence number, OR 70 
Addenda type code, OR 68, OR 70 
Adjustment entries, OR 25-OR 26, OR 90 
ADV. See Automated accounting advice 
Advice routing number, OR 71 
Alphameric 

defined, OR33 
Alteration of item, OR 9 
Amendment of the rules, OR 32 
American National Standards Institute 
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application control structure, OR 33 

interchange control structure, OR 33 

PIN requirements, OR 5, OR 12 
Amount of entry not accurately obtained code, OR 91 
Amounts, OR 71 

ANSI. See American National Standards Institute 
ANSIASCX12.5/X12.6 

defined, OR33 
Appeals, OR 143-OR 144 
Application control structure 

defined, OR33 
Arbitration 

procedures, OR 1 4 1-GR 144 

rules compliance, OR 1 
ARC entries. See Accounts receivable entries 
Article 4A 

defined, OR33 
ASC. See Accredited Standards Committee 
Associations. See also National Automated Clearing House Association 

defined, OR33 

requirements of, OR 3 1-OR 32 

warranties of, OR 30-OR 31 
ATX entries. See Financial EDI acknowledgment entries 
Audits 

Internet-initiated entries, OR 1 1, OR 15 

liabilities ofODFIs, OR 6 

rule compliance requirements, OR 1, OR 13 5-OR 138 
Authorization and agreement 

compliance with requirements, OR 4 

exception to requirement, OR 3 

by originator, OR 2 

by receiver, OR 2-OR 3 

revocation of, OR 5 

telephone-initiated entries, OR 3 

termination by operation of law, OR 5 

by third-party sender, OR 2 
Authorization code, OR 71 
Authorization records, OR 1 5 
Authorization revoked by customer code, OR 91 
Automated accounting advice 

ACH Operator obligations, OR 27 

file record format, OR 47-OR 48 

format specifications, OR 82 
Automated accounting information, OR 27 
Automated Clearing House 

defined, OR33 
Automated Clearing House Operators 

check truncation entries, OR 2 8-OR 29 

codes used by, OR 95-OR 96 

data elements, OR 70 

defined, OR 32-OR 33 

general rules, OR 1-OR 2 

indemnity of association, or 31 

negligence and willful misconduct, OR 31 -OR 32 

not agent of participating DFI, OR 32 

obligations of, OR 27-OR 28 

receiving, OR 36 

record of entries requirement, OR 28 

return and rejection by, OR 27 

reversing files notification, OR 6-OR 7 
Automated contested dishonored returns, OR 109-OR 1 14 
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Automated dishonored returns, OR 104-OR 108 
Automated enrollment entries 

defined, OR 34 

format specifications, OR 83 

prerequisites, OR 3-OR 4 

return by Federal Government Agency code, OR 93 

sequence of records, OR 55 
Automated notifications of change. See Notifications of change 
Automated return entries, OR 89-OR 90 
Automatic batch rejection, OR 86-OR 87 
Automatic entry detail return entry, OR 87-OR 89 
Automatic file rejection, OR 86 

b ■:. 

Backvaluation,OR139 
Banking day 

defined, OR 33 
Batch count, OR 71 
Batch level reject option, OR 86 
Batch number, OR 71 
Beginning segment for payment order/remittance advice 

defined, OR 33 
Beneficiary deceased code, OR 92 
Benefit payments 

liability of RDFIs, OR 17-OR 18 
Block count, OR 71 
Blocking factor, OR 71 
BPR/BPS data segment 

defined, OR 33 
Business day 

defined, OR 33 



Card expiration date, OR 7 1 

Card transaction type code, OR 68, OR 71 

Cash concentration or disbursement entries 

defined, OR 34 

format specifications, OR 82 

ODFI agreement to accept, OR 22 

sequence of records, OR 51 
CBR entries. See Corporate cross-border payments 
CCD entries. See Cash concentration or disbursement entries 
Change codes, OR 71 

tables of, OR 115-OR 117 
Change of beneficiaries, OR 141 
Check digit, OR 71-OR 72 
Check digit error code, OR 93 
Check serial number, OR 72 

Check truncation entries. See Truncated check entries 
CIE entries. See Customer initiated entries 
Code values, OR 68-OR 70 
Company/batch control records 

entry hash, OR 75 

specifications, OR 40, OR 45 
Company/batch header records 

acknowledgment entries, OR 129 

contested dishonored returns, OR 1 10-OR 1 1 1 

cross-border returns, OR 105, OR 111 
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dishonored returns, OR 104 

notifications of change, OR 1 18-OR 1 19 

refused acknowledgment entries, OR 132 

refused notifications of change, OR 123-OR 124 

return records, OR 97-OR 98 

specifications, OR 39, OR 45, OR 46 
Company descriptive date, OR 72 
Company discretionary data, OR 72 
Company entry description, OR 72-OR 73 
Company identification, OR 73 
Company name, OR 73 
Compensation rules, OR 1, OR 138-OR 141 
Complaints. See Arbitration 
Construction rules, OR 37-OR 38 
Consumer accounts 

adjustment entries, OR 25 

copy of debit authorization, OR 13 

defined, GR34 

notice to receiver of variable debits, OR 13 

recredits, OR 24 

stop payment orders, OR 22 
Consumer cross-border payments. See also Cross-border payments 

batch header record format, OR 46 

defined, OR 33, OR 35 

format specifications, OR 83 

sequence of records, OR 57 
Contested dishonored return reason code, OR 73 
Contested dishonored returns, OR 20, OR 109-OR 1 14 
Copying items, OR 8, OR 10, OR 13 
COR. See Notifications of change 
Corporate cross-border payments. See also Cross-border payments 

batch header record format, OR 46 

defined,OR33 

format specifications, OR 82 

sequence of records, OR 50 
Corporate customer advises not authorized code, OR 92 
Corporate entry detail records. See also Entry detail records 

acknowledgment entries, OR 131 

contested dishonored returns, OR 1 12 

dishonored returns, OR 106 

notifications of change, OR 120 

refused acknowledgment entries, OR 134 

refused notifications of change, OR 125 

return entries, OR 99 

specifications, OR 39 
Corporate trade exchange entries 

defined, OR34 

format specifications, OR 82-OR 83 

ODFI acceptance, OR 22 

sequence of records, OR 53 
Corrected data, OR 73 
Corrected returns, OR 20, OR 109 
Correcting files, OR 7 
Credit entries 

choice of law, OR 2 

returned, OR 19 
Credit entry refused by receiver code, OR 92 
Crediting entries, OR 16-OR 17 
Cross-border payments. See also Consumer cross-border payments; Corporate cross-border payments 

addenda records, OR 102 

agreements, OR 29 
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coding error, OR 94 
■■ company/batch header records, OR 98, OR 105, OR 1 1 1 

dishonor of return, OR 30 

notifications of change, OR 1 19 

originating gateway operator as participating DFI, OR 30 

receiving gateway operator as participating DFI, OR 30 

refused notifications of change, OR 124 

rules application, OR 3 0-OR 3 1 

scope, OR29 

third-party senders, OR 29 

warranties, OR 29-OR 30 
CTX entries. See Corporate trade exchange entries 
Customer advises not authorized code, OR 9 1-OR 92 
Customer initiated entries 

defined, OR 34 

format specifications, OR 82 

sequence of records, OR 52 

D '. 

Data acceptance specifications, OR 85-OR 89 
Data elements, OR 70-OR 85 
Data specifications, OR 38 
'.Date of death, OR 73 
Date original entry returned, OR 73 
Death notification entries 

defined, OR 34 

format specifications, OR 83 

RDFI receipt of, OR 18 

sequence of records, OR 54 
Death of a receiver, OR 17-OR 18 
Debit authorization, OR 13 
Debit entries, OR 16-OR 17, OR 24 
Debiting date change, OR 13 
Defenses, OR 8, OR 9 
Definition of terms, OR 3 2-OR 37 
Delays 

excused, OR 1 

six banking days, OR 6 

unexcused, OR 1 
Deposit Insurance Assessment 

defined, OR 139 
Depository Financial Institutions. See also Originating Depository Financial Institutions; Receiving Depository 
Financial Institutions 

audit requirements, OR 13 5-OR 136 
Description standards, OR 89 
Destroyed check entries 

defined, OR 37 

format specifications, OR 84 

origination, OR 8-OR 9 

return code, OR 92 

sequence of records, OR 67 
DFI account number, OR 73-OR 74 
DFIs. See Depository Financial Institutions 
Discretionary data, OR 74 
Dishonored returns 

automated, OR 104-OR 108 

codes used by the ODFI, OR 94-OR 95 

codes used by the RDFI, OR 95 

contested, OR 20, OR 73, OR 74, OR 109-OR 1 14 

corrected, OR 20, OR 109 
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cross-border payments, OR 30 

byODFI,OR20 

reason code, OR 74 

settlement date, OR 74 

specifications, OR 103-OR 108 

trace number, OR 74 
Disputes. See Arbitration 
DNE entries. See Death notification entries 
Document reference number, OR 74 
Duplicate enrollment code, OR 93 
Duplicate entry code, OR 92 




E . 

Effective entry date, OR 74-OR 75 
Electronic 

defined, OR34 
Electronic records 
defined, OR 34 
Electronic signatures 

defined, OR 34 
Electronic transmission requirements, OR 38 
Eligibility of items, OR 8 
Encoding, OR 9 
Endorsements 

restrictive, OR 10, OR 13 
ENR. See Automated enrollment entries 
Enrollment entries. See also Automated enrollment entries 

defined, OR34 
Entries 

defined, OR 34 

general rules, OR 1-OR 2 

reversing, OR 7 

timeliness of, OR 4 

transmission of, OR 5 
Entry/addenda count, OR 75 
Entry data 

defined, OR 34 

general rules, OR 1-OR 2 
Entry detail records. See also Corporate entry detail records 

acknowledgment entries, OR 130 

contested dishonored returns, OR 113 

dishonored returns, OR 107 

notifications of change, OR 120-OR 121 

refused acknowledgment entries, OR 133 

refused notifications of change, OR 125-OR 126 

return entries, OR 99-QR 100 

specifications, OR 39, OR 48-OR 67 
Entry detail sequence number, OR 75 
Entry hash, OR 75 
Excused delays, OR 1 
Existing relationship 

defined, OR 34 
Exposure limits, OR 4, OR 11 



Federal Funds Rate 
defined, OR 139 
Federal Reserve Banks, OR 21 
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Field inclusion requirements, OR 70 
File control records 

entry hash, OR 75 

specifications, OR 40, OR 44 
File creation date, OR 75 
File creation time, OR 75 
File header records, OR 35-OR 36 

specifications, OR 44 
File ID modifier, OR 75 
File identification, OR 75 
File level reject option, OR 86 
File record edit criteria code, OR 92 
Files 

acknowledgment, OR 85-OR 86 

correcting, OR 7 

defmed,OR34 

exchange specifications, OR 3 8-OR 43 

format data elements, OR 70-OR 85 

reversing, OR 6-OR 7 

structure, OR 39-OR 42 
Financial EDI acknowledgment entries 

defined, OR 33 

format specifications, OR 82, OR 129, OR 134 
Fines, national system, OR 144-OR 146 
Foreign exchange indicator, OR 75-OR 76 
Foreign exchange reference, OR 76 
Foreign exchange reference indicator, OR 76 
Foreign payment amounts, OR 76 
Foreign receiver's account number, OR 76 
Foreign receiving DFI identification, OR 76 
Foreign trace number, OR 76 
Format code, OR 76 

Format specification requirements, OR 12 
Forward valuation, OR 139-OR 140 
Fraud detection systems, OR 1 1, OR 15 



Good title, OR 8, OR 9 




Identification number, OR 77 
Immediate destination, OR 77 
Immediate origin, OR 77 
Improper source document code, OR 91 
Inbound entries 

defined, OR 34 
Individual card account number, OR 77 
Individual identification number, OR 77 
Individual name, OR 77-OR 78 
Ineligible item code, OR 94 
Information release, OR 12, OR 17 
Insolvency. See Knowledge of insolvency 
Insufficient funds code, OR 90 
Interchange control structure 

defined, OR 33 
Internet-initiated entries, OR 11 

annual audits, OR 1 1 , OR 1 3 

defined, OR 37 



OR 153 




INDEX 2005 OPERATING RULES 

format specifications, OR 84 

identity verification, OR 1 1, OR 15, OR 138 

obligations of originators, OR 15 

sequence of records, OR 66 
Invalid codes, OR 90, OR 92, OR 93 
ISO destination codes, OR 78 
ISO originating codes, OR 78 
Item altered code, OR 94 
Item research number, OR 78 
Item type indicator, OR 68, OR 78 

J. . 

Julian date on which advice is created, OR 78 

K. . 

Knowledge of insolvency, OR 8, OR 9 

L '■ 

Labels, OR 38. 

M 

MAC. See Message authentication code 
Machine transfer entries 

defined, OR 34 ' 

format specifications, OR 83 

PIN requirements, OR 12-OR 13 

rules application, OR 26 

sequence of records, OR 56 
Media specification requirements, OR 12 
Message authentication code, OR 78 
MICR information, OR 10, OR 14 
Midnight of a banking day 

defined,OR35 
Minimum description standards, OR 89, OR 115 
Misconduct of Operators, OR 3 1-OR 32 
MTE entries. See Machine transfer entries 

N 

National Association. See also National Automated Clearing House Association 

defined, OR35 

information requirements, OR 3 1 

protection from frivolous lawsuits, OR 32 

reports to, OR 28 
National Automated Clearing House Association 

protection from frivolous lawsuits, OR 32 

requirements of associations, OR 3 1-OR 32 

rules violations and, OR 145-OR 146 
Negligence of Operators, OR 3 1-OR 32 
Network identification code, OR 78 
No account code, OR 90 

Non-automated contested dishonored returns, OR 109-OR 1 14 
Non-automated return entries, OR 90 
Non-settled entries 

ACH Operator obligations, OR 27 
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defined, OR 35 
Non-transaction account code, OR 92 
Notice not provided code, OR 91, OR 94 
Notice obligation, OR 13, OR 14 
Notifications of change 

accounts receivable entries, OR 3 

automated, OR 82, OR 115, OR 117, OR 123, OR 125-OR 127 

converted, OR 117 

COR trace sequence number, OR 73 

corrected, OR 115 

format specifications, OR 82 

non-automated, OR 1 1 5 

ODFI and originator action, OR 20-OR 21 

RDFI warranties and indemnity, OR 20 

re-presented check entries, OR 3 

refused, OR 21, OR 82, OR 1 15, OR 1 17, OR 123-OR 127 

refused COR code, OR 81 

six banking days' delay, OR 6 

technical specifications, OR 1 15-OR 127 
Number of addenda records, OR 78 
Number of items paid, OR 78 

o .- ■' 

ODFIs. See Originating Depository Financial Institutions 
OGO. See Originating Gateway Operators 
Operators. See Automated Clearing House Operators 
Optional services, OR 27 
Organization 

defined, OR 35' 
Original entry trace number, OR 78-OR 79 
Original forward entry payment amount, OR 79 
Original receiving DFI identification, OR 79 
Original settlement date, OR 79 
Originating Automated Clearing House Operator 

defined, OR35 
Originating Depository Financial Institutions 

acceptance of debit entries, OR 22 

audit requirements, OR 137-OR 138 

closed facilities, OR 1 

codes used for automated dishonored return entries, OR 940R 95 

cross-border payment agreements, OR 29 

defined, OR 35 

dishonor of return entries, OR 20, OR 30 

effect of closing on time of settlement, OR 22 

exposure limits, OR 4, OR 1 1 

liabilities of, OR 6 

non-settled entries, OR 27 

notice by, OR 4 

notice to originator, OR 4 

notifications of change, OR 20-OR 21 

payment to, OR 15 

recalls, OR22 

request for return, OR 22 

return entries, OR 19-OR 21 

rules compliance, OR 1 

warranties of, OR 4-OR 6, OR 9, OR 10, OR 1 1 
Originating DFI identification, OR 79 
Originating Gateway Operators 

cross-border payment agreements, OR 29, OR 30 

defined,OR35 
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identification, OR 78 
Origination of entries 

accounts receivable entries, OR 9-OR 1 

destroyed check entries, OR 8-OR 9 

Internet-initiated entries, OR 1 1 

liabilities of ODFIs, OR 4-OR 6 

media and format specification requirements, OR 12 

prenotifications, OR 6 

prerequisites, OR 2-OR 4 

re-presented check entries, OR 9-OR 10 

reclamation entries, OR 7-OR 8 

reinitiation of returned entries by originators, OR 12 

release of information, OR 12 

reversing entries, OR 7 

reversing files, OR 6-OR 7 

telephone-initiated entries, OR 11-OR 12 

warranties of ODFIs, OR 4-OR 6 
Originator status codes, OR 27, OR 68, OR 79 
Originators 

cross-border payment agreements, OR 29 

defined, OR35 

obligations of, OR 1 2-OR 15 
Outbound entries 

defined, OR 35 



Participating Depository Financial Institutions 

defined, OR 35 
Payment-related information, OR 17, OR 79-OR 80 
Payment stopped. See Stop payment codes; Stop payment orders 
Payment type code, OR 80 
PBR entries. See Consumer cross-border payments 
Periodic statements, OR 17 
Permissible return entry code, OR 92 
Person 

defined, OR 35 
Personal identification numbers 

requirements, OR 5, OR 12-OR 13 
PIN. See Personal identification numbers 
Point-of-purchase entries 

defined, OR 35-OR 36 

format specifications, OR 83 

liabilities of ODFIs, OR 6 

obligations of originators, OR 1 4-OR 15 

receiver's right to recredit, OR 22-OR 23 

receiver's written statement, OR 24 

right to adjustment, OR 25 

sequence of records, OR 58 
Point-of-sale entries 

defined, OR 36 

format specifications, OR 83 

PIN requirements, OR 12-OR 13 

sequence of records, OR 59 
POP entries. See Point-of-purchase entries 
POS entries. See Point-of-sale entries 
PPD entries. See Prearranged payment and deposit entries 
Prearranged payment and deposit entries 

defined, OR 36 

format specifications, OR 83 

sequence of records, OR 60 
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Prenotifications, 0R6, OR 16 
Presentation of item, OR 8, OR 9, OR 10 
Presented for payment code, OR 94 
Priority code, OR 80 
Process control field, OR 80 
Processing obligations, OR 27 

R ■'■' 

RCK entries. See Re-presented check entries 

RDFI. See Receiving Depository Financial Institutions 

Re-presented check entries 

defined, OR36 

format specifications, OR 83 

notification, OR 3 

obligations of originators, OR 13 

origination, OR 9-OR 10 

receiver's right, OR 22-OR 23 

receiver's written statement, OR 24 

right to adjustment, OR 25-OR 26 

sequence of records, OR 61 

state law affecting acceptance code, OR 93 
Recalling entries, OR 22 
Receipt of entries 

crediting entries, OR 16-OR 17 

debiting entries 
OR 16-OR 17-' 

entry information, OR 16 

liability of RDFI for benefit payments, OR 17-OR 18 

notice to receiver, OR 16 

periodic statements, OR 16 

RDFI receipt of death notification entry, OR 18 

receipt and availability of entries, OR 16 

release of information, OR 17 

rights and obligations of RDFI, OR 16 

warranties of RDFI, OR 16 
Receipts 

point-of-purchase entries, OR 14-OR 15 
Receivers 

defined, .OR 36 
Receiver's election, OR 13 
Receiver's written statements, OR 24 

Receiving Automated Clearing House Operators 
' defined, OR 36 ■ 

Receiving company name/ID number, OR 80 
Receiving Depository Financial Institutions 

audit requirements, OR 135-OR 136 

availability of entries, OR 16 

closed facilities, OR 1 

codes used for automated dishonored return entries, OR 95 
crediting entries, OR 16-OR 17 
debiting entries, OR 16-OR 17 
defined,- OR 36 

effect of closing on time of settlement, OR 21 
entry information, OR 16 
identification, OR 81 

liability for benefit payments, OR 17-OR 18 

non-settled entries, OR 27 

noticeby,OR4 

notice to receiver, OR 4, OR 17 

notifications of change, OR 20, OR 21 
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periodic statements, OR 17 

receipt of death notification entry, OR 18 

receipt of entries, OR 17 

reimbursement of, OR 17 

right to adjustment, OR 25-OR 26 

rights and obligations, OR 16 

rules compliance, OR 1 

warranties, OR 16, OR 26 
Receiving Gateway Operators 

cross-border payment agreements, OR 30 

defined,OR36 
Receiving points 

defined, OR"36 
Reclamation entries, OR 5, OR 7-OR 8 
Record format specifications, OR 43-OR 85 
Record size, OR 81 
Record type codes, OR 68, OR 81 
Records 

code values, OR 68-OR 70 

defined, OR36 

electronic, OR 1-OR 2 

ofentries,ORl,OR28 

formats, OR 43-OR 67 

obligations of originators, OR 14 

retention, OR 1-OR 2 
Recredit right not exclusive, OR 24-OR 25 
Recredit rights, OR 22-OR 25 
Reference code, OR 81 
Reference information, OR 81 
Refused acknowledgment code, OR 81 
Refused acknowledgment entries, OR 21 
Refused notifications of change. See Notifications of change 
Reinitiation of returned entries by Originators, OR 12 
Rejected entries 

by ACH Operator, OR 27 

check truncation entries, OR 28 

Reports 

to National Association, OR 28 
Representative payee deceased code, OR 92 

Request for item, OR 10 

Request for return, OR 22 

Reserved code, OR 90 

Restrictive endorsements, OR 10, OR 13 

RET entries. See Return entries 

Return entries 

ACH Operator reports, OR 28 

addenda records, OR 101-OR 102 

adjustment entries, OR 90 

automated, OR 89-OR 90 

check truncation entries, OR 28 

company/batch header records, OR 97-OR 98 

contested dishonored returns, OR 20, OR 73, OR 74, OR 109-OR 114 

destroyed checks, OR 9 

dishonored, OR 20, OR 30, OR 94-OR 95, OR 103-OR 108 

entry detail records, OR 99-OR 100 

format specifications, OR 83 o 

formats for automated and converted return entries, OR 96-OR 102 

nonrautomated, OR 90 

ODFI request, OR 22 

re-presented check entries, OR 10 

requirements of, OR 19 
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return reason codes, OR 90-OR 96 

six banking days' delay, OR 6 

technical specifications, OR 89-OR 1 14 
Return of erroneous entries, OR 140-OR 141 
Return reason code, OR 8 1 , OR 90-OR 96 
Return settlement date, OR 81 

Return trace number, OR 8 1 . 

Returned per ODFFs request code, OR 90 
Reversing entries, OR 7, OR 140-OR 141 
Reversing files, OR 6-OR 7 
KGO.See Receiving Gateway Operators 
Right to adjustment, OR 25-OR 26 
Right to recredit, OR 22-OR 25 
Right to return entries, OR 19 
Routing number error code, OR 93 
Routing number of ACH Operator, OR 81 
Routing number verification, OR 1 1, OR 15 
Rules amendment, OR 32 
Rules enforcement, OR 1, OR 145-OR 146 
Rules violations, OR 144-OR 146 




Security of Internet sessions, OR 15 
Send 

defined, OR 36 
Sending points 

defined, OR36 

liabilities ofODFIs, OR 6 
Sequence number within batch, OR 81 
Sequence of records, OR 38, OR 41-OR 42 
Service class codes, OR 68, OR 82 
Settlement, OR 21-OR22 
Settlement date, OR 36, OR 82 
Shared network transactions 

defined, OR37 

format specifications, OR 83 

PIN requirements, OR 12-OR 13 

rules application, OR 26 

sequence of records, OR 62 
SHR. See Shared network transactions 
Signature not genuine code, OR 93 
Signatures, OR 8, OR 9 
Single entries 

defined, OR 37 
Six banking days' delay, OR 6 
Source documents 

for accounts receivable entries, OR 10, OR 14 

for point-of-purchase entries, OR 14 

presented for payment code, OR 92-OR 93 

stop payment code, OR 93 
Standard entry class codes, OR 17, OR 68-OR 69, OR 82-OR 84 
Standard labels, OR 38 
Statements, periodic, OR 1 7 
Stop payment codes, OR 91, OR 93, OR 94 
Stop payment orders, OR 22 
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Tape specifications, OR 38 
Technical specifications 

ACH file exchange, OR 3 8-OR 43 

ACH record format, OR 43-OR 85 

acknowledgment entries, OR 1.2 8-OR 134 

arbitration procedures, OR 141-OR 144 

compensation rules, OR 13 8-OR 141 

data acceptance, OR 85-OR 89 

fines, national system, OR 144-OR 146 

minimum description standards, OR 89 

notifications of change, OR 1 15-OR 127 

return entries, OR 89-OR 114 

rule compliance audit requirements, OR 135-OR 138 
TEL entries. See Telephone-initiated entries 
Telephone-initiated entries 

defined, OR 37 

format specifications, OR 83 

obligations of originators, OR 15 

origination of entries, OR 1 1-OR 12 

sequence of records, OR 63 
Terminal city, OR 84 
Terminal identification code, OR 84 
Terminal location, OR 84 
Terminal state, OR 84 
Third-Party Senders 

audit requirements, OR 137-OR 138 

authorization and agreement, OR 2 

cross-border payments, OR 29 

defined, OR 35, OR 37 

exposure limits, OR 4, OR 1 1 

obligations of, OR 18-OR 19 

Originators and, OR 35 

revocation of authorization and agreement, OR 5 

transmission of entries, OR 5, OR 13 
Third-Party Service Provider 

defined, OR 37 
Total amount, OR 84 

Total debit or credit entry dollar amount, OR 84 
Trace number, OR 84-OR 85 
Trace number sequence, OR 43 
Transaction codes, OR 69-OR 70, OR 85 
Transaction date, OR 85 
Transaction description, OR 85 
Transaction serial number, OR 85 
Transaction time, OR 85 
Transaction type code, OR 85 
Transmit 

defined, OR 37 
TRC entries. See Truncated check entries 
Truncated check entries 

defined, OR 37 

eligible participants, OR 28 

format specifications, OR 28, OR 84 

inconsistencies, OR 29 

return and rejection, OR 28 

return code, OR 92 

rules application, OR 28-OR 29 

scope, OR 28 

sequence of records, OR 64 
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warranties, OR 28 
Truncated entries exchange 

defined, OR 37 

format specifications, OR 28, OR 84 

rules application, OR 28-OR 29 

sequence of records, OR 65 
Truncation 

defined, OR37 
TRX entries. See Truncated entries exchange 

U ; - ■:■" 

Unable to locate account code, OR 90 
Unauthorized debits, OR 17, OR 24 
Uncollected funds code, OR 91 
Unexcused delays, OR 1 
Uniform Commercial Code, OR 8, OR 34 
Unposted credit entries, OR 19 



Variable debits 

notice to receiver, OR 13 

w 

Waiver of right to recredit, OR 24 
Warranties 

of associations, OR 30-OR 31 

check truncation entries, OR 28 

cross-border payments, OR 29-OR 30 

destroyed check entries, OR 8 

liability for breach of, OR 6, OR 8, OR 10, OR 1 1, OR 29, OR 30, OR 31 

limitations, OR 6 

of ODFIs, OR 4-OR 6, OR 8, OR 10 

ofRDFIs,OR16,OR26 

sending points, OR 6 

third-party senders, OR 18-OR 19 
WEB entries. See Internet-initiated entries 
Willful misconduct, ACH Operators, OR 3 1-OR 32 
Written statements under penalty of perjury, OR 24, OR 25, OR 26 

x ■;■' ' ■ 

XCK entries. See Destroyed check entries 

z '■■:.;: 

Zero dollar entries 

defined,OR37 
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PREFACE 



The NACHA Operating Guidelines manual has been 
prepared by the National Automated Clearing House 
Association (NACHA) to provide additional information 
and detail on the Automated Clearing House (ACH) 
Network and, where necessary, amplification of the 
NA CHA Operating Rules. It is intended to be used as a 
reference with the NA CHA Operating Rules. In case of 
any inconsistency or conflict between the Operating Rules 
and this manual, the Operating Rules shall govern. 

This manual provides basic information related to the 
ACH Network, as well as information related to those 
institutions participating in or directly interfacing with the 
ACH Network. 

The stated purpose of NACHA is to develop and promote 
the national exchange of electronic entries among 
participating depository financial institutions. For such a 
system to function effectively, a high degree of uniformity 
among individual ACH participants is essential. The 
NACHA Operating Rules provides a common set of rules 
that applies to entries flowing between ACH participants. 
These rules still permit a degree of latitude at the local 
level in developing specific procedures for the ACH 
operation and participation by depository financial 
institutions exchanging ACH transactions in a local 
environment. 

While this manual applies specifically to interregional 
entries, it should be a guide for all ACH processing in the 
absence of local procedures. It must be stressed that 
participants must adhere to the procedures established by 
their local ACH payment association or ACH Operator. 
It is the responsibility of each association to ensure that its 
procedures comply with the NA CHA Operating Rules. 
Some procedures described in this manual, though not 
mandatory, are recommended by NACHA as sound 
practices. Deviation from or alteration of these 
procedures on the local level should be done only after 
careful consideration, recognizing that local procedures 
may vary. However, under no circumstance should any 
local procedures be developed that conflict with the 
NACHA Operating Rules for processing interregional 
entries. 



In addition to the rules set forth in the NACHA Operating 
Rules and the information provided in the NACHA 
Operating Guidelines, ACH entries are also subject to 
applicable federal and state law, such as the Electronic 
Fund Transfer Act (EFTA) and Article 4A of the Uniform 
Commercial Code. The EFTA governs certain electronic 
funds transfers, including ACH entries to or from a natural 
person's personal, family, or household account. Article 
4A covers certain credit funds transfers, including ACH 
credit transactions not subject to the EFTA. The NA CHA 
Operating Rules have been drafted to reflect such federal 



and state law and, where appropriate, to incorporate 
certain provisions of such law. For example, certain of 
the NACHA Operating Rules applying to corporate 
transactions have been adopted or amended in light of 
Article 4A. These rules or amendments do not apply to, 
and have no effect by negative implication or otherwise, 
on an ACH transaction not subject to Article 4A, 
including a corporate transaction not subject to Article 
4A.' ■ 

The manual is organized so that each participant can 
locate all responsibilities and procedures relating to it by 
consulting as few chapters as possible. The manual is 
divided into four sections and provides guidelines for 
implementation of the NACHA Operating Rules 'currently 
in effect. Implementation guidelines for rule amendments 
becoming effective later in the year are also included, with 
implementation dates for these amendments noted within 
the text. Section I relates to the participants in the ACH 
Network and outlines the responsibilities of each and its 
relationship to the other participants. Section II is divided 
into four chapters: Originator, Originating Depository 
Financial Institution, ACH Operator, and Receiving 
Depository Financial Institution. Section III provides 
information on functional procedures within the ACH 
Network. Each function is broken down into the 
responsibilities of each participant in the system. The 
functions described are Prenotifications, Notifications of 
Change, Returns, Reversals, Acknowledgment Entries, 
and Customer-Initiated Entries. Section III provides 
supporting chapters on areas related to ACH processing 
that may or may not be specific requirements within the 
Rules. Section IV covers special topics. One important 
chapter in this section is Mapping, where a sample 
consumer application is placed into the PPD format The 
chapter also shows how an entry from the sample 
application is placed within the return format, the 
notification of change format, the dishonored return 
format and the contested dishonored return format. Other 
chapters within this section include information on Third- 
Party Service Providers, Addenda Records, OFAC 
Compliance, Audit Controls and Compliance, National 
System of Fines, Arbitration and Compensation, 
Automated Enrollment Entries, Destroyed Check Entries, 
Cross-Border Payments, Re-presented Check Entries, 
Point-of-Purchase Entries, Accounts Receivable Entries, 
Internet-Initiated Entries, and Telephone-Initiated Entries. 
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A. DEVELOPMENT OF THE SYSTEM 




The need to improve the nation's payments system was 
recognized as imperative in the late 1960s. Special task 
forces began to develop a workable alternative to paper 
checks before the volume became overwhelming. A 
direct result of the early groundwork was the 
establishment of the first automated clearing house ( ACH) 
for the exchange of paperless entries, the Calwestern 
Automated Clearing House Association (CACHA), in 
1972. At the same time, several other clearing house 
associations set up Special Committees on Paperless 
Entries (SCOPE) to implement similar automated 
facilities. In most areas, agreements were made between 
the local ACH associations and the Federal Reserve Bank 
serving the area to provide the facilities, equipment, and 
staff to operate an automated clearing house. 

As the number of ACH associations increased, each 
elected to contract with the regional Federal Reserve Bank 
or a private organization to operate ACH processing 
facilities. Those ACH associations which elected to 
operate their own facilities settled transactions through the 
local Federal Reserve Bank. In 1974, the National 
Automated Clearing House Association (NACHA) was 
formed to coordinate the ACH movement nationwide. By 
1978, there were multiple ACH associations covering the 
entire continental United States, operating under the 
standards established by NACHA. Alaska, Hawaii, 
Guam, and Puerto Rico are also served by ACH 
associations. 

For the most part, an ACH Operator processing entries on 
a local basis served the depository financial institutions in 
its geographic area of responsibility. However, in early 

1977, as a result of joint efforts by NACHA and the 
Federal Reserve System, a project was implemented 
linking ten local ACH Operators into an interregional 
exchange pilot project, with a goal of establishing a 
nationwide ACH Network if the pilot project proved a 
viable means of transferring funds. By the end of 1977, 
the pilot had demonstrated that the ACH would prove a 
workable means of transmitting certain types of electronic 
payments throughout the country. The next logical step 
was the expansion of the program to provide for a 
coast-to-coast ACH Network. Arrangements were made 
between NACHA and the Federal Reserve System to 
implement an interregional exchange system by the end of 

1978. The ACH Network also allows a financial 
institution in one geographic region to originate and/or 
receive entries from an ACH Operator in another 
geographic region. Processing arrangements and 



agreements must be in place prior to the handling of 
entries in this manner. 

Significant changes have occurred since the initial 
development of the system. In 1 979, format revisions to 
support Customer Initiated Entries (CIE) and Machine 
Transfer Entries (MTE) were introduced to support new 
services. In 1981, an Extended Processing Cycle, which 
permits a next-day settlement with a later cutoff for 
Originators, was implemented to provide for more rapid 
collection of funds for corporate consolidation. This 
cycle was initially restricted to debits and delayed ACH 
files but was later expanded to support electronic return 
entries. Restrictions were later removed so any 
transaction could be processed in that cycle. 

In 1 982, NACHA sponsored a study in which 
corporations defined their needs for the movement of both 
funds and other data. As a result, the NACHA Operating 
Rules were modified to support corporate transfers. These 
modifications permitted multiple addenda records to be 
used with each funds transfer entry, thus enabling the 
Originator to supply accounting and other information 
concerning the transaction to the Receiver. 

The Corporate Trade Payment (CTP) format was 
developed to permit the transmission of remittance 
information to the Receiver using a fixed field format. 
During the same time frame in which CTP was being 
introduced, the American National Standards Institute's 
(ANSI) Accredited Standards Committee (ASC) X12 was 
working to develop electronic data interchange standards 
for common business transactions and other transactions 
between corporate buyers and sellers. All ANSI ASC 
X12 messages, including the X12.4 Payment 
Order/Remittance Advice, use a variable length message 
with a broad data dictionary. Because the CTP format 
and X12.4 Payment Order/Remittance Advice format 
were not compatible, NACHA and ANSI committees met 
in 1985 to resolve these discrepancies. The ANSI ASC 
X12.4 Payment Order/Remittance Advice was modified 
and additional fields were added to communicate 
information concerning the transfer of funds when 
transmitting through several payment mechanisms. These 
new fields permitted an Originating Depository Financial 
Institution (ODFI) to convert the ASC XI 2.4 Payment 
Order/Remittance Advice to the CTP format. 

A new ACH transaction, called the Corporate Trade 
Exchange (CTX), was also developed so the XI 2.4 data 
could accompany the funds transfer without reformatting. 
The CTX format incorporated the strengths of both the 
NACHA fixed record format and the variable length 
record format of ASC XI 2. The traditional 94-character 
fixed format was used in the Company/Batch Records so 
the funds transfer could be executed with the ACH 
software already in place. A revised addenda record was 
developed which continued the support of the 94- 
character standard. However, 80 characters of each 
addenda record were made available for payment related 
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information. The ANSI ASCX12.4 Payment 
Order/Remittance Advice could be transmitted via the 
ACH delivery mechanism by using these payment related 
fields, the funds transfer could be effected, and the 
payment related data could be delivered to the receiving 
corporation in the XI 2.4 format. With this approach, the 
funds transfer, accounting, and payment related 
information remain together. As a result of the versatility 
of the CTX format, use of the CTP format was eliminated 
in September 1996. 

Point-of-Sale specifications, effective in 1 985 and 
amended in 1988, allow the ACH to be used as a delivery 
mechanism for debit card transactions. 

As we moved through the 1990s, the use of ANSI ASC 
X'1'2 ': standards for electronic data interchange (EDI) 
became more popular among corporations: This 
increased popularity encouraged greater use of both the 
CCD and GTX formats. Both ODFIs and RDFIs began to 
offer a variety of services to corporations for the 
processing of remittance data, on both the originating side 
and the receiving side of the AGH transaction. 

In 1992, two important rule amendments were adopted to 
support the efforts of the U.S. Department of the Treasury 
and the practice of check clearing facilities when cash 
letters are lost or destroyed. The Death Notification Entry 
allows a government agency (e.g., Social Security 
Administration) to notify a financial institution that the 
recipient of a government benefit payment has died. The 
Destroyed Check application allows a financial institution 
to utilize the ACH Network to facilitate the clearing of 
certain checks when those checks have been inadvertently 
destroyed in the check clearing process. 

In 1996, the Automated Enrollment Entry was developed 
as an optional alternative to the paper enrollment methods 
used by many Federal Government Agencies, enabling the 
ACH Network to be utilized by depository financial 
institutions to transmit consumer ACH credit enrollment 
information on behalf of their customers to Federal 
Government Agencies. In 1998, the Automated 
Enrollment process was expanded to allow enrollments 
for both future ACH credit and ACH debit transactions to 
be transmitted to Federal Government Agencies by DFIs 
on behalf of both consumers and companies. 

In 1997, the ACH Network was expanded to permit the 
transmission of acknowledgment entries by RDFIs, at 
their option, to indicate that corporate credit entries (CCD 
or CTX entries) have been received by the RDFI and that 
the RDFI will attempt to post the payments to the 
Receivers' accounts. 

In 1998, the ACH Network was also expanded to 
accommodate re-presented check entries, which allow for 
me truncation and electronic collection of checks that are 
returned due to insufficient or uncollected funds. In 



September 2000, a new Standard Entry Class Code, RCK, 
was implemented for this application. 

In 1999, the ACH Network was further expanded to 
accommodate point-of-purchase entries, which allow for 
the origination of non-recurring ACH debit entries to 
consumer accounts for in-person payments made by 
consumers at the point-of-purchase. This debit 
application, which requires a consumer to provide the 
merchant with a check for use as a source document for 
the consumer's bank routing and account information, 
provides Originators with an alternative to accepting the 
consumer's check as the method of payment In 
September 2000, a new Standard Entry Class Code, POP, 
was implemented for this application. Also in 1 999, a 
short-term rule became effective that established a legal 
framework within which ACH participants could pilot test 
acceptance of an application allowing the truncation of 
consumer checks received through the U.S. mail for the 
payment of goods or services and the collection of those 
checks via the ACH Network. The short-term rule 
remained in effect until March 2002, at which time a new 
application, Accounts Receivable Entries (ARC) was 
implemented. 

In 2000, two Standard Entry Class Codes were 
implemented for cross-border payments : CBR (Corporate 
Cross-Border Payment) and PBR (Consumer Cross- 
Border Payment). These new SEC Codes improved the 
efficiency of transmitting consumer and corporate cross- 
border ACH transactions. 

During 200 1 , two new Standard Entry Class Codes, WEB 
(Internet-Initiated Entries) and TEL (Telephone-Initiated 
Entries), became effective. These SEC Codes facilitate 
access to the ACH Network by providing Originators with 
additional options (i.e., the Internet and the telephone) for 
obtaining a Receiver 's authorization for ACH debit entries 
while, at the same time, heightening security requirements 
for ACH entries authorized via alternative media that bear 
a potentially greater risk profile. 

In 2002, a new Standard Entry Class Code, ARC 
(Accounts Receivable Entries), was implemented and 
established a legal framework for the conversion of 
consumer checks received by Originators via the U.S. 
mail or at a dropbox location into ACH debit entries to 
consumers' accounts. 

The Automated Clearing House System is designed to 
serve all depository financial institutions (DFIs), 
regardless of size, on an equitable basis. The basic 
relationship between DFIs and their customers, their 
correspondents, and me ACH remains essentially the same 
as under the paper check system. For example, the DFI 
that has its deposit accounting performed by a larger 
computerized correspondent may receive electronic 
payments through that correspondent or directly from the 
ACH Operator. 
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B. OVERVIEW OF THE SYSTEM 

1. PARTICIPANTS 

The following entities participate in the ACH system. 
They are defined as: 

Originator 

The Originator is the entity that agrees to initiate ACH 
entries into the payment system according to an 
arrangement with a Receiver. The Originator is usually a 
company directing a transfer of funds to or from a 
consumer's or another company's account. In the case of 
a customer initiated entry, however, the Originator maybe 
an individual mitiatmg fiands transfer activity to or from 
his or her own account. The term "company" is intended 
to be representative of the Originator of electronic ACH 
entries and does not imply exclusion of other types of 
organizations. 

Originating Depository Financial Institution 

The Originating Depository Financial Institution (ODFI) 
is the institution that receives the payment instructions 
from Originators and forwards the entries to the ACH 
Operator. A DFI may participate in the ACH as a 
Receiving Depository Financial Institution (RDFI) 
without being an ODFI; however, if a DFI chooses to 
originate ACH entries, it must also agree to act as an 
RDFI. 

Automated Clearing House Operator 

An Automated Clearing House (ACH) Operator is the 
central clearing facility, operated by a Federal Reserve 
Bank (FRB) or a private organization, that receives entries 
from ODFIs, distributes the entries to appropriate RDFIs, 
and performs the settlement functions for the affected 
financial institutions. For a complete description of an 
ACH Operator, refer to the chapter on ACH Operators 
within Section II of these Guidelines. 

Receiving Depository Financial Institution 

The Receiving Depository Financial Institution (RDFI) is 
the DFI that receives ACH entries from the ACH Operator 
and posts them to the accounts of its depositors 
(Receivers). 

Receiver 

A Receiver is a natural person or an organization that has 
authorized an Originator to initiate an ACH entry to the 
Receiver's account with the Receiving DFI. 



Third-Party Service Provider 



In some instances, an Originator, ODFI, or RDFI may 
choose to use the services of a Third-Party Service 
Provider for all or part of the process of handling ACH 
entries. A Third-Party Service Provider is an entity other 
than the Originator, ODFI, or RDFI that performs any 
functions of behalf of the Originator, ODFI, or RDFI with 
respect to the processing of ACH entries. A function of 
ACH processing can include, but is not limited to, the 
creation of ACH files on behalf of an Originator or ODFI, 
or acting as a Sending Point or Receiving Point on behalf 
of an ODFI or RDFI, respectively. 

As the ACH Network continues to evolve, Third-Party 
Service Providers have taken on larger and more complex 
roles in the processing of ACH transactions. For a 
detailed discussion of the specific roles and 
responsibilities of Third-Party Service Providers, refer to 
the Third-Party Service Provider Chapter within Section 
IV of these Guidelines. 

Figure 1 below depicts the system participants and their 
interrelationships. 
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Figure 1 - System Participants 

2. PAYMENT APPLICATIONS 

The ACH Network supports a number of different 
payment applications. Unlike me wire transfer and check 
systems, the ACH is both a credit and a debit payment 
system. An Originator initiating entries into the system 
will code the entries in such a manner as to indicate the 
type of payment, such as a debit or credit. Also, the 
application is either consumer or corporate in nature, i.e., 
me funds transfer affects either a consumer account or a 
corporate account at the RDFI. Each ACH application is 
identified and recognized by a specific Standard Entry 
Class Code, which appears in the ACH record format. 
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The Standard Entry Class Code also identifies the specific 
computer record format that will be used to carry the 
payment and payment related information relevant to the 
application. ACH entries may be transmitted to a variety 
of account types. Both credit and debit entries may be 
transmitted to demand accounts, savings accounts, and 
financial institutions' general ledger accounts. Credit 
entries only (with the exception of reversals to correct 
erroneous credit transactions) may be transmitted to loan 
accounts. Following is a list of Standard Entry Class 
Codes and the different products each code supports. 

a) Consumer Applications 

ARC - Accounts Receivable Entry 

This Standard Entry Class Code enables Originators to 
convert to a Single-Entry ACH debit a consumer check 
received via the U.S. mail or at a dropbox location for the 
payment of goods or services. The consumer's source 
document (i.e.-, the check) is used to collect the 
consumer's routing number, account number, check serial 
number, and dollar amount for the transaction. 

CIE - Customer Initiated Entry 

Customer Initiated Entries are limited to credit 
applications where the consumer initiates the transfer of 
funds to a company for payment of funds owed to that 
company, typically through some type of home banking 
product or bill payment service provider. 

MTE - Machine Transfer Entry 

The ACH Network supports the clearing of transactions 
from Automated Teller Machines, i.e., Machine Transfer 
Entries (MTE). 



PBR - Consumer Cross-Border Payment 

This Standard Entry Class Code is used for the 
transmission of consumer cross-border ACH credit and 
debit entries. This SEC Code allows cross-border 
payments to be readily identified so that financial 
institutions may apply special handling requirements for 
cross-border payments, as desired. The PBR format 
accommodates detailed information unique to cross- 
border payments (e.g., foreign exchange conversion, 
origination and destination currency, country codes, etc.). 

POP - Point-of-Purchase Entry 

This ACH debit application is used by Originators as a 
method of payment for the in-person purchase of goods or 
services by consumers. These Single-Entry debit entries 
are initiated by the Originator based on a written 
authorization and account information drawn from the 
source document (a check) obtained from the consumer at 
the point-of-purchase. The source document, which is 
voided by the merchant and returned to the consumer at 



the point-of-purchase, is used to collect the consumer's 
routing number, account number, and check serial number 
that will be used to generate the debit entry to the 
consumer's account. 

PPD - Prearranged Payment and Deposit Entry 

Direct Deposit 

Direct deposit is a credit application that transfers funds 
into a consumer's account at the Receiving Depository 
Financial Institution. The funds being deposited can 
represent a variety of products, such as payroll, interest, 
pension, dividends, etc. 

Freauthorized Bill Payment 



Preauthorized payment is a debit application. Companies 
with billing operations may participate in the ACH 
through the electronic transfer (direct debit) of bill 
payment entries. Through standing authorizations, the 
consumer grants the company authority to initiate periodic 
charges to his or her account as bills become due. This 
concept has met with appreciable success in situations 
where the recurring bills are regular and do not vary in 
amount -- insurance premiums, mortgage payments, and 
installment loan payments being the most prominent 
examples. Standing authorizations have also been 
successful for bills where the amount does vary, such as 
utility payments. 

POS/SHR - Point of Sale Entry/Shared Network 
Transaction 

These two Standard Entry Class Codes represent point of 
sale debit applications in either a shared (SHR) or non- 
shared (POS) environment. These transactions are most 
often initiated by the consumer via a plastic access card. 

RCK - Re-presented Check Entry 

A re-presented check entry is a Single-Entry ACH debit 
application used by Originators to re-present a check that 
has been processed through the check collection system 
and returned because of insufficient or uncollected funds. 
This method of collection via the ACH Network, 
compared to the check collection process, provides 
Originators with the potential for improvements to 
processing efficiency (such as control over timing of the 
initiation of the debit entry) and decreased costs. 




TEL -Telephone-Initiated Entry 

This Standard Entry Class Code is used for the origination 
of a Single-Entry debit transaction to a consumer's 
account pursuant to an oral authorization obtained from 
the consumer via the telephone. This type of transaction 
may only be originated when there is either ( 1 ) an existing 
relationship between the Originator and the Receiver, or 
(2) no existing relationship between the Originator and the 
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Receiver, but the Receiver has initiated the telephone call 
This SEC Code facilitates access to the ACH Network by 
providing an alternative authorization method, oral 
authorization via the telephone, for certain types of 
consumer debit entries. 

WEB \- Internet-Initiated Entry 

This Standard Entry Class Code is used for the origination 
of debit entries (either recurring or Single-Entry) to a 
consumer's account pursuant to an authorization that is 
obtained from the Receiver via the Internet. This SEC 
Code helps to address unique risk issues inherent to the 
Internet payment environment through requirements for 
added security procedures and obligations. 

b) Corporate Applications 

C3R - Corporate Cross-Border Payment 

This Standard Entry Class Code is used for the 
transmission of corporate cross-border ACH credit and 
debit entries. This SEC Code allows cross-border 
payments to be readily identified so that financial 
institutions may apply special handling requirements for 
cross-border payments, as desired. The CBR format 
accommodates detailed information unique to cross- 
border payments (e.g., foreign exchange conversion, 
origination and destination currency, country codes, etc.). 

CCD - Cash Concentration or Disbursement 

This application, Cash Concentration or Disbursement, 
can be either a credit or debit application where funds are 
either distributed or consolidated between corporate 
entities. This application can serve as a stand-alone funds 
transfer, or it can support a limited amount of payment 
related data with the funds transfer. 



a CCD credit entry utilize the ACK format. 
Acknowledgments initiated in response to a CTX credit 
entry utilize the ATX format. 

ADV - Automated Accounting Advice 

This Standard Entry Class Code represents an optional 
service to be provided by ACH Operators that identifies 
automated accounting advices of ACH accounting 
information in machine readable format to facilitate the 
automation of accounting information for Participating 
DFIs. 

COR -Automated Notification of Change or Refused 
Notification of Change 

This Standard Entry Class Code is used by an RDFI or 
ODFI when originating a Notification of Change or 
Refused Notification of Change in automated format. It 
is also used by the ACH Operator that converts paper 
Notifications of Change to automated format. 

DNE - Death Notification Entry 

This application is utilized by a Federal Government 
agency (e.g., Social Security Administration) to notify a 
depository financial institution that the recipient of a 
government benefit payment has died. 

ENR -Automated Enrollment Entry 

This optional SEC Code allows a depository financial 
institution to transmit ACH enrollment information to 
Federal Government Agencies via the ACH Network for 
future credit and debit applications on behalf of both 
consumers and companies. 

TRC/TRX- Truncated Entries 



CTX- Corporate Trade Exchange 

The Corporate Trade Exchange application supports the 
transfer of funds (debit or credit) within a trading partner 
relationship in which a full ANSI ASC X 12 message or 
payment related UN/EDIF ACT information is sent with 
the funds transfer. The ANSI ASC XI 2 message or 
payment related UN/EDIF ACT information is placed in 
multiple addenda records. 

c) Other Applications 

ACE/ATX ' - Acknowledgment Entries 

These optional Standard Entry Class Codes are available 
for use by the RDFI to acknowledge the receipt of ACH 
credit payments originated using the CCD or CTX 
formats. These acknowledgments indicate to the 
Originator that the payment was received and that the 
RDFI will attempt to post the payment to the Receiver's 
account. Acknowledgment entries initiated in response to 



This Standard Entry Class Code is used to identify batches 
of truncated checks. For more information on check 
truncation, please see the National Association for Check 
Safekeeping Guidelines available fromNACHA. 

XCK - Destroyed Check Entry 

This application can be utilized by a collecting institution 
for the collection of certain checks when those checks 
have been destroyed. 

3. ADVANTAGES TO PARTICIPANTS 

Each participant in the ACH Network benefits through 
improvements in service and reductions in operating 
costs. The following specific advantages have been 
identified for each participant: 
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Advantages to Consumers 

• Direct deposit offers the following benefits to the 
recipient: 

- Elimination of time and cost involved in depositing 
checks. 

■'.-■. Consistent availability of funds on a timely basis, 
even during vacation, illness, or business trips. 

- Elimination ofthe possibility of lost or stolen checks. 

■• Debit applications provide the following benefits to the 
consumer: 

- Convenience of not having to write checks. 

- Elimination of postage expense and the risk of late 
payments. 

- Avoidance of late or interest charges through 
prompt, timely payments. 

'.'■-■ Establishment of excellent payment and credit 
records. 



° Enhanced public recognition through provision of 
effective, efficient, and innovative payment services. 

Advantages to the Receiving Depository Financial 
Institution 

8 Reduction of costs through automated processing of 
electronic entries and elimination of handling 
individual items. 

° Alleviation of teller-line congestion during peak 
periods (particularly on payday). 

• Ability to offer improved services to both consumer 
and corporate account holders. 

•Enhanced public recognition through provision of 
effective, efficient, and innovative payment services. 



SECTION II 

PARTICIPANT RELATIONSHIPS 

AND RESPONSIBILITIES 



Advantages to Companies (Originators or Receivers) CHAPTER I ORIGINATORS 

■ • ■ Reduction of administration and operating expenses. 



• Elimination of time lost by employees who deposit 
checks during working hours. 

• Reduction of clerical cost for account reconciliation. 

• Elimination of stop payment charges and check reissue 
■' ■ costs. 

• Reduced remittance processing costs (paper handling) 
resulting from the absence ofthe check. 

• Accelerated availability of funds. 

• Better cash management forecasting. 
. •'.■ Improved business relationships. 

• Certainty of delivery. 

• Possible reduction of bank service charges. 

Advantages to the Originating Depository Financial 
Institution 

• Reduction of costs through increased automated 
processing. 

'•: New opportunities for increased business through 
expanded services. 



'A. INTRODUCTION 

An Originator initiates entries into the Automated 
Clearing House Network through a relationship with an 
Originating Depository Financial Institution (ODFI). 

Examples of Originators are: 

V An employer offering its employees direct deposit of 
payroll or an organization (company, financial 
institution) offering direct deposit of certain funds 
(interest, dividends, retirement funds, etc.). 

• A company or billing firm that offers direct payment 
(debits) to those consumers that owe a recurring or one 
time obligation. 



An organization that consolidates or disburses funds 
from or to its subsidiaries or branches. 

A corporate entity that enters into a trading partner 
agreement with a corporate receiver for the purpose of 
transferring funds according to that agreement. 

A merchant or financial institution that offers point of 
sale activity to consumers. 

An individual that initiates an entry via a bill payment 
service to a company for monies owed. 
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• A company converting to electronic payments 
consumer checks received via the U.S. Mail or at a 
dropbox location. 

• ■ A company electronically re-presenting checks that 

have been returned for insufficient or uncollected 
funds. 

The ACH Network enables an Originator to prepare a 
batch of debit and/or credit entries to effect the transfer of 
funds via the ACH from or to Receivers' accounts. The 
Originator must initiate the batch(es) into the ACH 
Network according to an arrangement with an ODFI. 

The primary participant relationships for the Originator 
are with the Receiver and the ODFL The Originator's 
relationship with the ODFI and the Receiver involves both 
legal responsibilities and processing issues. 

B. LEGAL RESPONSIBILITIES - 

AGREEMENTS AND AUTHORIZATIONS 

1. ELECTRONIC RECORDS AND ELECTRONIC 
RECORD RETENTION 

The NACHA Operating Rules permit ACH participants to 
obtain and store ACH records electronically as an 
alternative to obtaining and retaining such documents in 
hard copy format. Specifically, the Rules allow any 
agreement, authorization, written statement under penalty 
of perjury, or other record required by the NACHA 
Operating Rules to be in writing to be obtained and 
retained in either hard copy or electronic form. 

Electronic Signatures and Records 

Electronic records include agreements, authorizations, 
written statements under penalty of perjury, or other 
records created, generated, sent, communicated, received, 
or stored by electronic means. Electronic records may 
have a signature requirement. 

Electronic signatures are electronic sounds, symbols, or 
processes attached to or logically associated with an 
agreement, authorization, written statement under penalty 
of perjury, or other record executed or adopted by a 
person with the intent to sign the record. These writing 
and signature requirements can be satisfied by compliance 
with the Global and National Commerce Act (E-Sign 
Act). Originators should be aware that any record that is 
signed according to the terms of an applicable state 
version of the Uniform Electronic Transaction Act is 
considered to have been signed in conformance with the 
terms of the E-Sign Act 

To satisfy the requirements of the NA CHA Operating 
Rules (and Regulation E for preauthorized debits), 
electronic signatures must "similarly authenticate'* the 
electronic records. The authentication method chosen 
must evidence both the signer's identity and his assent to 



the terms of the record. For purposes of the NACHA 
Operating Rules, ACH records may also be similarly 
authenticated using the same authentication methods 
currently prescribed for consumer debit authorizations - 
that is, the record may be similarly authenticated via the 
Internet through the use of a digital signature, PIN, 
password, shared secret, etc., or a hard copy record may 
be authenticated via the telephone by the consumer's 
speaking or key-entering a code provided on the record. 

Any other written notice or disclosure required by the 
NACHA Operating Rules but not requiring a signature 
may also be provided in electronic form, including e-mail. 
(This includes the notice for TEL entries. Please note that 
state and federal laws may require consumer consent 
before using electronic notices/disclosures.) 

Record Retention 

Originators are permitted to retain copies of ACH records 
in electronic form, provided that the electronic record (1) 
accurately reflects information contained within the 
record, and (2) is capable of being accurately reproduced 
for later reference, whether by transmission, printing, or 
other reproduction. 

Originators choosing to utilize electronic communication 
methods for the retention of ACH records should 
implement practices and procedures to ensure that 
electronic records of ACH documents accurately reflect 
the information contained within the document and that 
both the electronic record and a recorded record of the 
authentication can be accurately reproduced for future 
reference. 

Originators should be aware that other ACH participants 
may also utilize electronic methods to obtain and retain 
records of ACH documents. In such cases, Originators 
can expect to receive electronic versions, rather than hard 
copies, of documents that they request from other ACH 
participants. 

2. RELATIONSHIP WITH ODFI 

The Originator must execute an agreement or contract 
with the ODFI that, at a minimum, binds the Originator to 
the NACHA Operating Rules. The agreement, among 
other things, defines the parameters of the relationship 
between the two parties, identifies processing 
requirements for the specific application(s), and 
establishes liability and accountability for certain 
procedures related to the application(s). Originators 
should be aware that, under the terms of this agreement, 
such liabilities may include, but are not limited to, the 
amount of any fines assessed against the ODFI for a rules 
violation caused by the Originator. In some instances, 
provisions of the agreement may be superseded by 
applicable federal or state law (e.g., Uniform Commercial 
Code Article 4A or the Electronic Fund Transfer Act). 
The following table lists specific issues that either may or 
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may not be addressed in the NA CHA Operating Rules, but 
which the Originator and its ODFI may wish to 
specifically define in their agreement. The matrix to the 
left of each item indicates whether the issue pertains to 
debit and/or credit consumer applications or debit and/or 
credit corporate applications. Originators must be aware 
that they are subject to applicable U.S. law when initiating 
ACH transactions. This includes, among other things, that 
the Originator is not violating the Office of Foreign Assets 
Control (OF AC)-enforced sanctions, and is not acting on 
behalf of, or transmitting funds to or from, any party 
subject to such sanctions. For additional information 
about OF AC requirements as they relate to Originators, 
refer to the discussion on Processing Requirements and 
Responsibilities -- Relationship With ODFI within this 
chapter. Detailed information on OF AC compliance can 
be found within Section IV, Special Topics, of these 
Guidelines. Originators are encouraged to interface with 
their ODFIs via a secured telecommunications link for all 
ACH-related activity. This includes the origination and/or 
receipt of all current ACH transactions, related reports, 
returns, NOCs, and any future related applications. 
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Consumer 

DR. CR. 
X X 

XX 
X X 

X X 
X X 
X X 

X 

X X 

X 

X 
X X 

X X 

X X 
X X 

XX 

X 

X 

X X 



Corporate 

DR. CR. Issues That Should Be Defined in Agreement Between Originator and ODFI 
X 



X 
X 



X 



X 



X 
X 

X 

X 

X 
X 



X The nature, format and medium of entries, or entry information to be furnished by the 
Originator. 

X The place and time the entries or entry information is to be furnished by the Originator. 



X The level of security to be established for delivering the payment data from the Originator 
to the ODFI, such as transmittals with authorized signatures, the method used to verify 
authenticity of telecommunicated data, etc. 



X Responsibilities of the participating ODFI and Originator with respect to remaking rejected 
entries or files. 

X The deadline for reversals, corrections, or changes by the Originator of entries or entry 
information furnished to the ODFI. 

X The ODFFs responsibility for delay by the ACH Operator or RDFI in processing any credit 
or debit the DFI transmits to the ACH Operator, or failure to process or credit or debit any 
such entry or other acts of omission of a third party. 

X Alternative actions that may be taken in the event of late payments. 

X Whether the agreement covers credit or debit entries or both. 

The time when the funds may be available to the Originator. 

X The time when funds are to be provided to the ODFI by the Originator. 

X The charges or fees by the ODFI for providing services to the Originator under the 
agreement. 

X Responsibilities of the ODFI and Originator with respect to handling Returns, Notifications 
of Change, Dishonored Returns, and Refused Notifications of Change. 

X The conditions under which a Third-Party Service Provider will be utilized. 

X Procedures for terminating the agreement and time frames under which the processing of 
entries under that agreement will cease. 

X The Originator's obligation regarding prenotification transactions, if prenotification process 
is used. 

The Originator's obligation to obtain, retain, and provide copies of consumer authorizations, 
particularly with regard to Regulation E. 

The Originator's obligation with respect to consumer alleged errors under Regulation E. 

X The Originator's responsibility for matters warranted by the ODFI pertaining to entries 
exchanged through the ACH Network. 

For RCK entries, the following warranties should be addressed: 

The ODFI has good title to the returned item. 
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Consumer Corporate 

DR. CR. DR. CR. Issues That Should Be Defined in Agreement Between Originator and QDFI (continued) 

• All signatures on the item are authentic and authorized. 

• The item has not been altered. 

• The item is not subject to a defense or claim. 
° ITie 

• The entry accurately reflects the item. 
The item will not be presented unless the related entry has been returned by the 

RDFL ':^;;-. : ^y-:;^^y^ . ' / '.' 

• Theinfom in magnetic ink on the item is correct. 
'. • Any restrictive endorsement placed on the item is void or ineffective. 

The GDFI will provide the RDFI with a copy of the front and back of the item 
within ten banking days of the RDFI's written request for a copy, provided that the 
request for a copy of me item was received within seven years of the settlement date 
oftheRCK entry. 

For Internet-Initiated Entries, the folio wing warranties should be addressed: 

Each Originator of WEB entries has employed a commercially reasonable 
fraudulent transaction detection system. 

• Each Originator of WEB entries has employed commercially reasonable methods 
of authentication to verify the identity of the Receiver. 

In the case of a WEB entry initiated by an Originator that is not a natural person or 
by a Third-Party Sender, the ODFI has (1) established procedures to monitor the 
credit- worthiness of that Originator or Third-Party Sender on an on-going basis, (2) 
established an exposure limit for that Originator or Third-Party Sender, (3) 
implemented periodically, and (4) 

implemented procedures to monitor entries initiated by that Originator or Third- 
Party Sender relative to its exposure limit across multiple settlement dates. 

• Each Originator that initiates WEB entries has used commercially reasonable 
procedures to verify that routing numbers are valid. 

.■•■'.. Each Originator of WEB entries must conduct an annual audit to ensure that the 
financial information it obtains from Receivers is protected by security practices 
and procedures that include, at a minimum, adequate levels of ( 1 ) physical security 
to protect against theft, tampering, or damage, (2) personnel and access controls to 
protect against unauthorized access and use, and (3) network security to ensure 
secure capture, storage, and distribution. 

For Telephone-Initiated Entries, the following warranties should be addressed: 

.•'■"■■■. Each Originator of TEL entries (1) has employed commercially reasonable 
procedures to verify the identity of the Receiver, and (2) has utilized commercially 
reasonable procedures to verify that routing numbers are valid. (Although not 
explicitly defined as an ODFI warranty with respect to TEL entries, the 
ODFI/Originator agreement should also address the requirement of the ODFI to 
provide reporting information to the National Association for each Originator of 
TEL entries whose return rate for unauthorized entries exceeds 2.5%, as required 
by these rules.) 

For Accounts Receivable Entries, the following warranties should be addressed: 

• ■ . ' The amount of the entry, the routing number, the account number, and the check 
serial number are in accordance with the source document. 
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Consumer Corporate 

DR. CR DR. CR. Issues That Should Be Defined in Agreement Between Originator and ODFI (continued) 



The Originator must retain a reproducible, legible image, microfilm, or copy of the 
front of the Receiver's source document for each ARC entry for two years from the 
Settlement Date of the ARC entry. An RDFI that receives an ARC entry may send 
to the ODFI that originated the entry a written request for a copy of the source 
document to which the ARC entry relates. The RDFI's written request must be 
received by the ODFI within two years of the Settlement Date of the ARC entry. 
Upon receipt of the written request, the ODFI warrants to the RDFI that it will send 
a copy of the front of the Receiver's source document within ten ( 1 0) banking days. 
The copy must indicate that it is a copy on its face. 

The source document to which the ARC entry relates will not be presented or 
returned such that any person will be required to make payment based on the source 
document. In addition to each RDFI, ACH Operator, and Association, this warranty 
runs to any other party that may be liable on the source document. 
The source document to which the ARC entry relates must be destroyed within 
fourteen days of the Settlement Date of the entry. 

Although not explicitly defined as a distinct warranty for the ODFI with respect to 
ARC entries, the ODFI/Originator agreement should also address the Originator's 
obligation to establish reasonable procedures under which the Receiver may notify 
the Originator that receipt of his checks does not constitute authorization for ARC 
entries to the Receiver's account. 



For Point-of-Purchase Entries, the following warranties should be addressed: 

The source document provided to the Originator for use in obtaining the Receiver's 
routing number, account number; and check serial number for the initiation of the 
POP entry (1) is returned voided to the Receiver after use by the Originator, and (2) 
has not been provided to the Receiver for use in any prior POP entry. 

X The Originator's responsibility for cancellation of authorization and the application of the 

"adjustment" right with respect to on-us entries. 

XX X X Use of proper authorization methods, authorization forms, and ACH formats. 

XX X X The use of appropriate encryption standards for ACH entries involving banking information 

mat is transmitted or exchanged via an Unsecured Electronic Network. 

X Responsibilities of the ODFI and Originator with respect to handling Acknowledgment 
entries, if such transactions are desired by the Originator. 

X X X X An acknowledgment by the Originator that ACH transactions it originates comply with the 

provisions of U.S. law. 

X X X X The conditions under which fines and/or liabilities, imposed against the ODFI for amies 

violation caused by an action/inaction of the Originator, will be assessed against the 
Originator. 
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NOTE: Following is a sample ACH agreement between the 
Originator and the ODFI. This sample contract is provided for 
illustrative purposes only and does not include any appendices, 
schedules, etc., that may be referenced within this sample 
agreement. The Originator's and ODFI's legal departments should 
review the contract to ensure that it meets the needs of both 
organizations. Most ODFIs have standard service agreements 
available. Originators and ODFIs may want to revise their 
contracts to include provisions related to The Electronic Signatures 
and Global and National Commerce Act. 

Discussion of Sample ODFI-Originator Agreement 

The Sample Agreement appears below. It is for use by the ODFI with 
corporate customers, not individuals, desiring to originate credit entries 

only.- '■. 

Recitals 



Recital A establishes the type of funds transfer to which the Sample 
Agreement applies: credit entries initiated pursuant to the NACHA 
Operating Rules and any other applicable local ACH Association rules. 
Recital B provides that the capitalized terms in the Sample Agreement 
have the meanings ascribed to such terms in the NACHA Operating 
Rules. 

Section 1: Transmittal Of Entries by Company 

Section 1 establishes the type(s) of ACH credit entries the Originator 
will transmit to the ODFI. It further provides that the Originator will 
transmit such entries in compliance with the location, format and other 
requirements upon which the ODFI and Originator have agreed and 
which appear on Schedule A to the Sample Agreement. This section 
also sets a limit on the total dollar amount of entries which may be 
initiated by the Originator on any one day. 

Section 2: Security Procedure 

Section 2(a) requires the ODFI and Originator to comply with the 
security procedure described in Schedule B to the Sample Agreement. 
The allocation of liability resulting from unauthorized entries will in 
certain circumstances depend upon the security procedure used for the 
detection of such entries. The Sample Agreement does not set forth a 
specific security procedure because each Originator and ODFI will wish 
to develop an appropriate security procedure for their particular 
situation. The consequences of compliance (or noncompliance) with 
this security procedure are specified in Section 3 of the Sample 
Agreement. 

Section 2(a) also provides that the purpose of the security procedure is 
not to detect errors in the content or transmission of Entries, but solely 
for verifying the sender of the Entry. 

Section 2(b) provides that the Originator is responsible for establishing 
and maintaining the security procedures that it utilizes. The section 
further provides that the Originator is responsible for notifying the 
ODFI if such security procedures are compromised. 

Section 3: Compliance With Security Procedure 

Section 3 sets forth the consequences of compliance (or noncompliance) 
with the security procedure agreed to by the Originator and ODFI and 
specified on Schedule B of the Sample Agreement. 

Section 3(a) is concerned with entries (or requests for cancellation or 
amendment) received by the ODFI which were not authorized by the 
Originator. It provides that the ODFI will not be liable for payment of 
an entry (or acting on such a request) where the ODFI has acted in 
compliance with the security procedure referred to in Schedule B of the 
agreement. If Article 4A applies, the liability of the ODFI for certain 
unauthorized entries (or requests) cannot be varied by agreement of the 
parties. Therefore, if Article 4 A is applicable, Section 3(a) will only be 
effective if the security procedure provided for relates to the authenticity 
of entries and is "commercially reasonable," the ODFI has acted in good 
faith, and the Originator fails to prove that issuance of the entry was not 



caused by an agent of the Originator or a person with access to the 
Originator's transmitting facilities or who obtained information from a 
source controlled by the Originator. 

Section 3(a) also provides that, if signature comparison is to be used as 
a part of the security procedure, the ODFI shall be deemed to have 
complied with that part of the procedure if it compares the signature 
accompanying a file of entries (or request) received with the signature 
of an authorized representative of the Originator and, on the basis of this 
comparison, the ODFI believes the signature accompanying the file to 
be that of the authorized representative. Under Article 4A, signature 
comparison is not "by itself a security procedure, reasonable or 
otherwise. 



Section 3(b) is concerned with erroneous or duplicate entries initiated 
by the Originator. It makes the Originator responsible for entries it 
initiates, whether or not the ODFI has complied with an agreed upon 
security procedure and whether or not the entry is erroneous. 
Section 3(b) varies by agreement, as permitted under Article 4A, the 
rule imposing liability in certain instances on the ODFI for executing 
erroneous or duplicate payment orders transmitted by the Originator. 

Section 4: Recording and Use of Communications 

In this section, the ODFI and Originator authorize each other to record 
and store telephone conversations and data transmissions. An ODFI 
may use these records for demonstrating compliance with a security 
procedure when fraud has occurred. 

Section 5: Processing, Transmittal And Settlement By Financial 
Institution 

Section 5 obligates the ODFI to process and transmit to a designated 
ACH Operator not on-us entries complying with applicable file 
specifications and received by the ODFI in a timely manner and 
containing an appropriate effective entry date as specified in 
Section 5(b). It also contains specific rules as to the time and manner 
in which the ODFI must transmit entries. Section 5(c) provides that if 
the entry does not meet certain timing requirements specified in Section 
5(b), the ODFI shall use reasonable efforts to transmit the entry by the 
next applicable deposit deadline. 

These obligations are subject to Section 7 of the Sample Agreement, 
which details circumstances under which the ODFI will reject an ACH 
entry transmitted by the Originator to the ODFI. 

Section 6: On-Us Entries 

Section 6 deals with the ODFI's obligations with respect to on-us 
entries. Specifically, under Section 6, the ODFI agrees to credit the 
amount of on-us entries complying with the requirements of 
Section 5(b)(0 anQl 00 of the Sample Agreement to the Receiver's 
account on the effective entry date. Section 6 also provides that if the 
on-us entry does not meet certain timing requirements specified in 
Section 5(b), the ODFI shall use reasonable efforts to credit the 
Receiver's account on the next business day following the effective 
entry date. That ODFI obligation is also subject to Section 7 of the 
Sample Agreement, which details circumstances under which the ODFI 
will reject an on-us entry transmitted to it by the Originator. 

Under Article 4A, if an ODFI and an Originator have not agreed to the 
payment date of an entry as provided in Section 6, payment must be 
made as instructed by the Originator or on the date of receipt of the 
entry. : 

Section 7: Rejection of Entries 

Section 7 sets forth the circumstances in which the ODFI may reject an 
entry transmitted to it by an Originator. In addition, it sets forth the 
time and means of giving notice of such rejection, and provides that the 
ODFI will have no liability by reason of such rejection or the time of 
giving such notice. 

Section 7 complies with the time requirements of Article 4A for giving 
notice of rejection so as to preclude (a) acceptance liability with respect 
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to on-us entries, and (b) interest liability with respect to on-us and other 
entries that might otherwise arise under Article 4A. 

Section 8: Cancellation or Amendment by Company 

Section 8 sets forth the conditions under which the ODFI will accept a 
cancellation or amendment from the Originator. Section 8 provides that 
the Originator has no right to cancel or amend an entry after its receipt 
by the ODFI, (i.e., the ODFI does not agree to post-acceptance 
cancellation or amendment). However, Section 8 further provides that 
the ODFI will, without liability for failure to effect a cancellation or 
amendment, use reasonable efforts to act on a request for cancellation 
or amendment prior to transmitting a not on-us entry to an ACH 
Operator, or prior to crediting the Receiver's account in the case of an 
on-us entry, provided the Originator's request complies with the security 
procedure described in Schedule B to the Sample Agreement. The 
section also provides that the Company will reimburse the Bank for any 
expenses, losses or damages the Bank may incur when it effects (or 
attempts to effect) the reversal of an Entry. 

Absent an agreement such as that contained in Section 8, Article 4A 
gives an Originator the right to cancel or amend an entry before the 
ODFI has accepted the entry. 

Section 9: Notice of Returned Entries 



Section 9 provides that the ODFI will notify the Originator of any entry 
returned to the ODFI by the ACH and that the ODFI has no obligation 
to retransmit such an entry if it has been properly formatted by the 
ODFI. This issue is not expressly addressed in Article 4A. 

Section J 0: Payment by Company for Entries 

Section 10 requires the Originator to pay the ODFI the amount of an 
entry on a specified date. To the extent the date fixed for such payment 
is after the date the ODFI transmits the entry to the ACH, or makes 
payment of an on-us entry to a Receiver, the ODFI will bear the risk that 
the Originator will be unable to meet its payment obligation. Under 
Article 4 A, there are circumstances under which the ODFI will be 
required to refund the payment made by the Originator as provided in 
Section 10, with interest, and certain ofthese Article 4A provisions may 
not be varied by agreement of the parties or a NACHA rule. 

Section 11: The Account 

Section 1 1 establishes the account relationship that will be utilized in 
connection with ACH transactions originated pursuant to the Sample 
Agreement. It requires the Originator to maintain a balance of available 
funds in the account designated by the Originator in Schedule D of the 
Sample Agreement sufficient to cover any payment obligation incurred 
as a result of an entry. s 

Section 1 1 also provides that the ODFI shall recredit the Originator's 
designated account with the amount of any such entries returned by the 
RDFI. In addition, it provides that the ODFI has a right to obtain 
payment of an entry originated by the Originator under the agreement 
by debiting the designated account, as well as any other account of the 
Originator, if the designated account does not contain sufficient 
available funds to cover the Originator's payment obligation. 

Section 12: Account Reconciliation 

Under Section 12, if the Originator does not notify the ODFI of a 
discrepancy within a given number of days (to be fixed by the 
agreement) following receipt of a periodic statement, then the ODFI will 
not be liable either for any loss of interest with respect to an entry or for 
any losses resulting from the Originator's failure to give such notice. 
Article 4A provides that an Originator must exercise ordinary care to 
advise the ODFI of an erroneous or unauthorized entry within a 
reasonable time, not to exceed 90 days, after receipt of notification of 
its transmittal. Failure to do so excuses the ODFI from its obligation to 
pay interest on the amount of unauthorized or erroneous entries for 
which it is liable. However, where Article 4A applies, such a provision 
is not effective to protect the ODFI from liability for the amount of such 
unauthorized or erroneous entries. 



Section 12 further provides that where an ODFI has accepted an entry 
issued in the name of the Originator and has notified the Originator of 
such acceptance, the Originator is precluded from asserting a 
discrepancy in its periodic statement if it fails to notify the ODFI thereof 
within a prescribed time period (to be fixed by the agreement) after 
receipt of the statement This section thus allows for a different 
preclusion period than the one year period prescribed in Article 4A. 
Please note, however, that for a transaction governed by Article 4A, it 
is unclear whether a provision with a preclusion period significantly 
shorter than one year will be found to be valid. 

Section 13: Company Representations And Agreements; Indemnity 

Under this section, the Originator agrees, among other things, to be 
bound by and comply with the NACHA Operating Rules. As required 
under Article 4A, this section provides notice to the Originator of, and 
the Originator agrees to, the NACHA provisional payment rule. An 
ODFI which fails to provide this notice and obtain this agreement 
concerning the NACHA provisional payment rule may incur liability 
under the NACHA Operating Rules and Article 4 A. 

Section 14: Financial Institution Responsibilities; Liability; 
Limitations on Liability; Indemnity 

Section 14 deals with the responsibilities and liability of the ODFI to the 
Originator. 

Section 1 4(a) provides that the ODFI may rely solely on the information 
provided to it by the Company and shall only be liable for its negligence 
or willful misconduct in performing the services provided for in the 
Sample Agreement. It should be noted that if Article 4A is applicable, 
Section 14(a) may be overridden in certain instances. For example, 
Article 4A imposes liability upon an ODFI in circumstances other than 
ODFI negligence for the improper or delayed execution of an entry, and 
that liability cannot be varied by agreement of the parties. Similarly, 
under Article 4A, liability for the execution of unauthorized entries may 
be imposed on an ODFI without a showing that the ODFI was negligent, 
and this liability also may not be varied by agreement of the parties. 

Section 14(a) also reflects the NACHA rule that an ACH Operator is not 
an agent of the ODFI. Under Section 14(a) and the NACHA Operating 
Rules, as is permitted by Article 4A, the ODFI would not be responsible 
for errors of the ACH. 

Section 1 4(b) provides that the ODFI shall only be liable for Company's 
actual damages and shall not be liable for consequential, special, 
punitive, incidental or indirect damages incurred by the Originator in 
connection with the Sample Agreement. This provision is consistent 
with Article 4 A, which imposes no such damages on an ODFI, unless 
the parties agree to the contrary. Here, as in certain other parts of the 
Sample Agreement, the provision is not necessary because the ODFI is 
protected where Article 4 A applies, but may be necessary where it does 
not. 

Section 1 4(c) provides various reasons for which the ODFI shall not be 
liable for failing to act. For example, if the execution of an entry would 
cause the ODFI to exceed its sender net debit cap, the ODFI would not 
be liable for delaying execution of the entry. 

Section 1 4(d) establishes the rate of interest applicable in the event that 
the ODFI becomes obligated to the Originator for interest payments. 
The measure for the calculation of interest, the Federal Funds rate of the 
Federal Reserve Bank of New York, is consistent with the measure 
provided for in Article 4A. 

Section 15: Inconsistency of Name And Account Number 



Section 15 deals with an entry which describes the Receiver 
inconsistently by name and account number. Section 15 provides the 
Originator with notice that, where a Receiver is identified by both name 
and account number, the RDFI (or the ODFI in the case of an on-us 
entry) may make payment on the basis of the account number alone. 
Under Article 4A, if the RDFI (or the ODFI in the case of an on-us 
entry) does make payment of such an entry based on the account 
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number, the Originator will be obligated to pay for the entry, since it has 
previously been provided the notice contained in Section <1 5. 



Section 16: Notification of Change 



This section provides that the ODFI will notify the Originator of all 
notifications of change received by the ODFI relating to entries 
transmitted to the ODFI from the Originator. This section also specifies 
the manner and time by which the ODFI will provide such notice to the 
Originator. This is not a matter addressed in Article 4A. It reflects the 
NACHA rule imposing a notification obligation upon the ODFL 

Section 1 7: Payment for Services 

This section provides that the Originator shall pay the ODFI for the 
services provided pursuant to the Sample Agreement in accordance with 
the charges set forth in Schedule E to the Sample Agreement. Section 
1 7 also provides for these fees to be changed upon notice to the 
Company. Article 4 A generally does not address the charges to be paid 
by the Originator to the ODFI with respect to the transmission of 
entries. 

Section 18: Amendments 

Section 18 enables the ODFI to amend the provisions of the Sample 
Agreement upon notice to the Originator. Article 4A does not address 
the process by which the Originator and ODFI may amend their 
agreement. 

Section 19: Notices, Instructions, Etc. 

This section of the Sample Agreement covers notices and instructions 
between the ODFI and Originator. Section 1 9(a) provides that the ODFI 
is not required to act on any notice or instruction of the Originator, 
except as expressly provided in the Sample Agreement. Absent such a 
provision, Article 4A would require the ODFI to act upon certain 
instructions of the Originator, notwithstanding that such instructions 
may not have been expressly provided for in the Sample Agreement. 

Section 20: Data Retention 

Section 20 requires the Originator to retain data to remake entries for 
the time period agreed upon by the Originator and ODFL The matter of 
data retention is not addressed by Article 4A. However, given the fact 
that under Article 4A the Originator may assert that the ODFI is not 
entitled to payment from the Originator for an entry one year after 
notification of the entry was received by the Originator (or such other 
time period upon which the parties agree as specified in Section 12 of 
the Sample Agreement), the parties may wish to require documents to 
be retained for at least such one year period (or such other period 
specified in Section 12). 

Section 21: Tapes and Records 

This section specifies that all tapes, security procedures and other 
records used by the Bank for ACH transactions governed by the 
Agreement are the Bank's property. 

Section 22: Evidence of Authorization 

This section specifies that the Originator will (a) obtain all 
authorizations and consents required by the NACHA Rules and (b) 
retain such authorizations and consents for at least 2 years after their 
expiration. 

Section 23: Cooperation in Loss Recovery Efforts 

In this section the Bank and the Company each agree to cooperate with 
the other party in performing loss recovery efforts in the event either 
party may be liable to the other for damages. 

Section 24: Termination 

This section specifies the terms under which either party may terminate 
the agreement, and the consequences of such termination. 



Section 24 permits either party to cancel the Sample Agreement at any 
time, upon notice to the other. Following such a cancellation, the 
parties' rights and duties with respect to an entry delivered to the ODFI 
by the Originator would be governed by applicable state law. If the 
applicable law were Article 4 A, in some circumstances the ODFI could 
incur liability if it takes no action with respect to an entry transmitted 
to it by an Originator. 

Section 25: Entire Agreement 

Section 25 provides that the Sample Agreement and the Originator's 
account agreement with the ODFI together comprise the entire 
agreement of the parties with respect to the processing of credit entries. 
This section also states that, in the event of any inconsistency between 
the account agreement and the Sample Agreement, the Sample 
Agreement will govern. Therefore, ODFIs need not necessarily revise 
their current account agreements in light of inconsistent provisions in 
that agreement and the Sample Agreement. 

In addition, Section 25 provides that the Sample Agreement will be 
deemed amended to the extent required to prevent the ODFI from being 
bound to perform any unlawful act in violation of a statute, regulation 
or governmental policy. This clause is designed to prevent a court from 
finding the entire Sample Agreement to be void if compliance with a 
provision of the agreement would cause the ODFI to violate such a law, 
regulation or policy, and to avoid having the ODFI deemed in default 
for failure to perform such an act. As discussed previously, certain of 
the provisions of the Sample Agreement are, in certain circumstances, 
unenforceable under Article 4A, but have been included in the Sample 
Agreement to address transactions not subject to Article 4A. 

Section 26: Non-Assignment 

Section 26 prohibits the Originator from assigning any of its rights or 
obligations under the Sample Agreement to any party without the 
ODFFs prior written consent. 

Section 27: Waiver 

Section 27 allows the ODFI to waive any provision of the Agreement 
without changing its rights with respect to another transaction or 
modifying the terms of the Agreement. 

Section 28: Binding Agreement; Benefit 

Section 28 specifies the parties who may have rights under the Sample 
Agreement. Specifically, it provides that the agreement is solely for the 
benefit of the ODFI and the Originator. Thus, for example, this section 
is intended to preclude a Receiver from bringing a legal action against 
the Originator on the basis that the Originator violated one of its 
obligations to the ODFI under the Sample Agreement. 

Section 29: Headings 




This section is a standard provision stating that section headings are not 
part of the Sample Agreement. 

Section 30: Severability 

This section specifies that if one provision of the Agreement is found to 
be invalid, illegal, or unenforceable, that provision is to be severed from 
the remainder of the Agreement, which shall continue to be valid and 
enforceable. 

Section 31: Governing Law 

Article 4A provides that, in the absence of agreement to the contrary, 
the rights and duties of an Originator and ODFI are governed by the law 
of the jurisdiction in which the ODFI is located. Whether or not the 
parties agree that the law of the ODFFs state should govern their 
agreement, it would be advisable to include a choice of law provision 
in the Originator-ODFI agreement specifying the law of a particular 
state as governing the parties' rights and duties. In that connection, 
consideration should be given to selection of the law of a state which 
has adopted Article 4A, given the certainty and protection it provides. 
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NACHA has adopted a rule providing that the law of the State of New 
York will govern the rights and obligations of the ODFI and RDFI with 
respect to entries subject to Article 4A. If the ODFI desires to utilize 
this NACHA choice of law rule with respect to its relationship with the 
Originator, the ODFI could insert New York in Section 31 of the 
Sample Agreement or provide a notice of the type described earlier in 
the book. 

Sample ODFI-Qriginator Agreement 

NOTE : This is not a NACHA-recommended or suggested form. 
Please note that this sample contract is provided for illustrative 
purposesonly and does not include any appendices, schedules, etc., 
that may be referenced within this sample agreement. ODFIs and 
their customers should consult with their own counsel and rely on 
their own business judgment in determining to what, if any, extent 
they wish to utilize this form. 



SAMPLE AGREEMENT 

ODFI-ORIGINATOR (CORPORATE) 

AGREEMENT (CREDIT ENTRIES) 
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This Agreement, dated as of_ 



is between 



("Financial Institution"). 



("Company") and _ 



RECITALS 



A. Company wishes to initiate Credit Entries by means of the 
Automated Clearing House Network pursuant to the terms of this 
Agreement and the rules of the National Automated Clearing House 
Association and the [insert reference to any other applicable local ACH 
Association] (the "Rules"), and Financial Institution is willing to act as 
an Originating Depository Financial Institution with respect to such 
Entries. 

B. Unless otherwise defined herein, capitalized terms shall have 
the meanings provided in the Rules. The term "Entries" shall have the 
meaning provided in the Rules and shall also mean the data received 
from Company hereunder from which Financial Institution prepares 
Entries. 



AGREEMENT 

■ 1 ;.-...; : Transmittal of Entries By Company . Company shall transmit 
[CTX] [and/or] [CCD] credit Entries to Financial Institution to the 
location(s) and in compliance with the formatting and other 
requirements set forth in Schedule A attached hereto. The total dollar 
amount of Entries transmitted by Company to Financial Institution on 
any one day shall not exceed $ . 



Institution immediately followed by written confirmation . The 
occurrence of unauthorized access will not affect any transfers made in 
good faith by Financial Institution prior to receipt of such notification 
and within a reasonable time period to prevent unauthorized transfers. 

3. Compliance With Security Procedure . 

(a) If an Entry (or a request for cancellation or amendment of an 
Entry) received by Financial Institution purports to have been 
transmitted or authorized by Company, it will be deemed effective as 
Company's Entry (or request) and Company shall he obligated to pay 
Financial Institution the amount of such Entry even though the Entry (or 
request) was not authorized by Company, provided Financial Institution 
accepted the Entry in good faith and acted in compliance with the 
security procedure referred to in Schedule B with respect to such entry. 
If signature comparison is to be used as a part of that security procedure, 
Financial Institution shall be deemed to have complied with that part of 
such procedure if it compares the signature accompanying a file of 
Entries (or request for cancellation or amendment of an Entry) received 
with the signature of an authorized representative of Company (an 
"Authorized Representative") and, on the basis of such comparison, 
believes the signature accompanying such file to be that of such 
authorized representative. 

(b) If an Entry (or request for cancellation or amendment of an Entry) 
received by Financial Institution was transmitted or authorized by 
Company, Company shall pay Financial Institution the amount of the 
Entry, whether or not Financial Institution complied with the security 
procedure referred to in Schedule B with respect to that Entry and 
whether or not that Entry was erroneous in any respect or that error 
would have been detected if Financial Institution had complied with 
such procedure. 

4. Recording and Use of Communications . Company and 
Financial Institution agree that all telephone conversations or data 
transmissions between them or their agents made in connection with 
this Agreement may be electronically recorded and retained by either 
party by use of any reasonable means. 

5. Processing, Transmittal And Settlement By Financial 
Institution. 



2. 



Security Procedure . 



(a) Company and Financial Institution shall comply with the security 
procedure requirements described in Schedule B attached hereto with 
respect to Entries transmitted by Company to Financial Institution. 
Company acknowledges that the purpose of such security procedure is 
for verification of authenticity and not to detect an error in the 
transmission or content of an Entry. No security procedure for the 
detection of any such error has been agreed upon between the Financial 
Institution and Company. 

(b) Company is strictly responsible to establish and maintain the 
procedures to safeguard against unauthorized transmissions. Company 
warrants that no individual will be allowed to initiate transfers in the 
absence of proper supervision and safeguards, and agrees to take 
reasonable steps to maintain the confidentiality of the security 
procedures and any passwords, codes, security devices and related 
instructions provided by the Financial Institution in connection with the 
security procedures described in Schedule B, If Company believes or 
suspects that any such information or instructions have been known or 
accessed by unauthorized persons, Company agrees to notify Financial 



(a) Except as provided in Section 6, On-Us Entries and Section 7, 
Rejection of Entries , Financial Institution shall (i) process Entries 
received from Company to conform with the file specifications set forth 
in the Rules, (ii) transmit such Entries as an Originating Depository 
Financial Institution to (the "ACH") 
acting as an Automated Clearing House Operator, and (iii) settle for 
such Entries as provided in the Rules. 

(b) Financial Institution shall transmit such Entries to the ACH by the 
deadline of the ACH set forth in Schedule C attached hereto [one 
business day] [two business days] prior to the Effective Entry Date 
shown in such Entries, provided (i) such Entries are received by 
Financial Institution's related cut-off time set forth on Schedule C on a 
business day, (ii) the Effective Entry Date is at least _____ days after 
such business day, and (iii) the ACH is open for business on such 
business day. For purposes of this Agreement (x) a "business day" is a 
day on which Financial Institution is open to the public for carrying on 
substantially all of its business [other than a Saturday or Sunday], and 
(y) Entries shall be deemed received by Financial Institution, in the case 
of transmittal by tape, when received by Financial Institution at the 
location set forth in Schedule A, and in the case of transmittal by 
electronic transmission, when the transmission (and compliance with 
any related security procedure provided for herein) is completed as 
provided in Schedule A. 

(c) If any of the requirements of clause (i), (ii) or (iii) of Section 5(b) 
is not met, Financial Institution shall use reasonable efforts to transmit 
such Entries to the ACH by the next deposit deadline of the ACH 
following that specified in Schedule C which is a business day and a 
day on which the ACH is open for business. 

6. On-Us Entries . Except as provided in Section 7, Rejection of 

Entries , in the case of an Entry received for credit to an account 
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maintained with Financial Institution (an "On-Us Entry"), Financial 
Institution shall credit the Receiver's account in the amount of such 
Entry on the Effective Entry Date contained in such Entry, provided the 
requirements set forth in clauses (i) and (ii) of Section 5(b) are met. If 
either of those requirements is not met, Financial Institution shall use 
reasonable efforts to credit the Receiver's account in the amount of such 
Entry no later than the next business day following such Effective Entry 
Date. 

7. Rejection of Entries . Financial Institution may reject any Entry 
which does not comply with the requirements of Section 1 , Transmittal 
of Entries By Company , or Section 2, Security Procedure , or which 
contains an Effective Entry Date more than days after the 
business day such Entry is received by Financial Institution. Financial 
Institution may reject an On-Us Entry for any reason for which an Entry 
may be returned under the Rules. Financial Institution may reject any 
Entry if Company has failed to comply with its account balance 
obligations under Section 1 1 , The Account . Financial Institution may 
reject any entry if Company does not adhere to security procedures as 
described in Schedule B. Financial Institution shall notify Company by 
[phone] [electronic transmission] [in writing] of such rejection no 
later than the business day such Entry would otherwise have been 
transmitted by Financial Institution to the ACH or, in the case of an 
On-Us entry, its Effective Entry Date. Notices of rejection shall be 
effective when given. Financial Institution shall have no liability to 
Company by reason of the rejection of any such Entry or the fact that 
such notice is not given at an earlier time than that provided for herein. 

8. Cancellation or Amendment By Company . Company shall 
have no right to cancel or amend any Entry after its receipt by Financial 
Institution. However, if such request complies with the security 
procedures described in Schedule B for the cancellation of Data, 
Financial Institution shall use reasonable efforts to act on a request by 
Company for cancellation of an Entry prior to transmitting it to the 
ACH or, in the case of an On-Us Entry, prior tocrediting a Receiver's 
account, but shall have no liability if such cancellation is not effected. 
Company shall reimburse Financial Institution for any expenses, losses, 
or damages Financial Institution may incur in effecting or attempting to 
effect Company's request for the reversal of an entry. 

9. Notice of Returned Entries . Financial Institution shall notify 
Company by [phone] [electronic transmission] of the receipt of a 
returned entry from the ACH no later than [one business day] after the 
business day of such receipt. Except for an Entry retransmitted by 
Company in accordance with the requirements of Section I ^ Transmittal 
of Entries By Company , Financial Institution shall have no obligation 
to retransmit a returned Entry to the ACH if Financial Institution 
complied with the terms of this Agreement with respect to the original 
Entry. 

10. Payment by Company for Entries . Company shall pay 
Financial Institution the amount of each Entry transmitted by Financial 
Institution pursuant to this Agreement at such time on the [Settlement 
Date with respect to] [date of transmittal by Financial Institution 

of] such Entry as Financial Institution, in its discretion, may determine, 
and the amount of each On-Us Entry at such time on the Effective Entry 
Date of such Entry as Financial Institution, in its discretion, may 
determine. 

11. The Account . Financial Institution may, without prior notice 
or demand, obtain payment of any amount due and payable to it under 
this Agreement by debiting the account(s) of Company identified in 
Schedule D attached hereto (the "Account"), and shall credit the 
Account for any amount received by Financial Institution by reason of 
the return of an Entry transmitted by Financial Institution for which 
Financial Institution has previously received payment from Company. 
Such credit shall be made as of the day of such receipt by Financial 
Institution. Company shall at all times maintain a balance of available 
funds in the Account sufficient to cover its payment obligations under 
this Agreement. In the event there are not sufficient available funds in 
the Account to cover Company's obligations under this Agreement, 
Company agrees that Financial Institution may debit any account 
maintained by Company with Financial Institution or any affiliate of 
Financial Institution or that Financial Institution may set off against any 



amount it owes to Company, in order to obtain payment of Company's 
obligations under this Agreement. 

12. Account Reconciliation . Entries transmitted by Financial 
Institution or credited to a Receiver's account maintained with Financial 
Institution will be reflected on Company's periodic statement issued by 
Financial Institution with respect to the Account pursuant to the 
agreement between Financial Institution and Company. Company 
agrees to notify Financial Institution promptly of any discrepancy 
between Company's records and the information shown on any periodic 
statement. If Company fails to notify Financial Institution of any 
discrepancy within . . '■ . . : ( ) days of receipt of a periodic 
statement containing such information, Company agrees that Financial 
Institution shall not be liable for any other losses resulting from 
Company's failure to give such notice or any loss of interest or any 
interest equivalent with respect to an Entry shown on such periodic 
statement. If Company fails to notify Financial Institution of any such 
discrepancy within of receipt of such periodic statement, 
Company shall be precluded from asserting such discrepancy against 
Financial Institution. 

13. Company Representations And Agreements; Indemnity . With 
respect to each and every Entry initiated by Company, Company 
represents and warrants to Financial Institution and agrees that (a) each 
person shown as the Receiver on an Entry received by Financial 
Institution from Company has authorized the initiation of such Entry 
and the crediting of its account in the amount and on the Effective Entry 
Date shown on such Entry, (b) such authorization is operative at the 
time of transmittal or crediting by Financial Institution as provided 
herein, (c) Entries transmitted to Financial Institution by Company are 
limited to those types of Credit Entries set forth in Section 1 , 
Transmittal of Entries By Company , (d) Company shall perform its 
obligations under this Agreement in accordance with all applicable laws 
and regulations, including the sanctions laws administered by OFAC, 
and (e) Company shall be bound by and comply with the Rules as in 
effect from time to time, including, without limitation, the provision 
making payment of an Entry by the Receiving Depository Financial 
Institution to the Receiver provisional until receipt by the 
Receiving Depository Financial Institution of final settlement for such 
Entry. Company specifically acknowledges that it has received notice 
of the Rule regarding provisional payment and of the fact that, if such 
settlement is not received, the Receiving Depository Financial 
Institution shall be entitled to a refund from the Receiver of the amount 
credited and Company shall not be deemed to have paid the Receiver 
the amount of the Entry. Company shall indemnify Financial Institution 
against any loss, liability or expense (including attorneys' fees and 
expenses) resulting from or arising out of any breach of any of the 
foregoing representations or agreements. 

14. Financial Institution Responsibilities; Liability; Limitations on 
Liability; Indemnity . 

(a) In the performance of the services required by this Agreement, 
Financial Institution shall be entitled to rely solely on the information, 
representations, and warranties provided by Company pursuant to this 
Agreement, and shall not be responsible for the accuracy or 
completeness thereof. Financial Institution shall be responsible only for 
performing the services expressly provided for in this Agreement, and 
shall be liable only for its negligence or willful misconduct in 
performing those services. Financial Institution shall not be responsible 
for Company's acts or omissions (including without limitation the 
amount, accuracy, timeliness of transmittal or authorization of any 
Entry received from Company) or those of any other person, including 
without limitation any Federal Reserve Financial Institution, Automated 
Clearing House or transmission or communications facility, any 
Receiver or Receiving Depository Financial Institution (including 
without limitation the return of an Entry by such Receiver or Receiving 
Depository Financial Institution), and no such person shall be deemed 
Financial Institution's agent. Company agrees to indemnify Financial 
Institution against any loss, liability or expense (including attorneys' 
fees and expenses) resulting from or arising out of any claim of any 
person that the Financial Institution is responsible for any act or 
omission of Company or any other person described in this 
Section 14(a). 
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(b) Financial Institution shall be liable only for Company's actual 
damages; in no event shall Financial Institution be liable for any 
consequential, special, incidental, punitive or indirect loss or damage 
which Company may incur or suffer in connection with this Agreement, 
whether or not the likelihood of such damages was known or 
contemplated by the Financial Institution and regardless of the legal or 
equitable theory of liability which Company may assert, including, 
without limitation, loss or damage from subsequent wrongful dishonor 
resulting from Financial Institution's acts or omissions pursuant to this 
Agreement. 

(c) Without limiting the generality of the foregoing provisions, 
Financial Institution shall be excused from failing to act or delay in 
acting if such failure or delay is caused by legal constraint, interruption 
of transmission or communication facilities, equipment failure, war, 
emergency conditions or other circumstances beyond Financial 
Institution's control. In addition, Financial Institution shall be excused 
from failing to transmit or delay in transmitting an Entry if such 
transmittal would result in Financial Institution's having exceeded any 
limitation upon its intra-day net funds position established pursuant to 
present or future Federal Reserve guidelines or in Financial Institution's 
reasonable judgment otherwise violating any provision of any present 
or future risk control program of the Federal Reserve or any rule or 
regulation of any other U.S. governmental regulatory authority. 

(d) Subject to the foregoing limitations, Financial Institution's 
liability for loss of interest resulting from its error or delay shall he 
calculated by using a rate equal to the average Federal Funds rate at the 
Federal Reserve Financial Institution of New York for the period 
involved. At Financial Institution's option, payment of such interest 
may be made by crediting the Account resulting from or arising out of 
any claim of any person that Financial Institution is responsible for any 
act or omission of Company or any other person described in 
Section 14(a). 

1 5. Inconsistency of Name And Account Number . Company 
acknowledges and agrees that, if an Entry describes the Receiver 
inconsistently by name and account number, payment of the Entry 
transmitted by Financial Institution to the Receiving Depository 
Financial Institution may be made by the Receiving Depository 
Financial Institution (or by Financial Institution in the case of an On-Us 
Entry) on the basis of the account number supplied by the Company, 
even if it identifies a person different from the named Receiver, and that 
Company's obligation to pay the amount of the Entry to Financial 
Institution is not excused in such circumstances. 

16. Notifications of Change . Financial Institution shall notify 
Company of all notifications of change received by Financial Institution 
relating to Entries transmitted by Company by [e.g., mail] no later than 
_____ business days after receipt thereof. 

17. Payment for Services . Company shall pay Financial Institution 
the charges for the services provided in connection with this Agreement, 
as set forth in Schedule E attached hereto. All fees and services are 
subject to change upon __ calendar days prior written notice from 
Financial Institution to Company. Such charges do not include, and 
Company shall be responsible for payment of, any sales, use, excise, 
value added, utility or other similar taxes relating to such services, and 
any fees or charges provided for in the agreement between Financial 
Institution and Company with respect to the Account (the "Account 
Agreement"). 

18. Amendments . From time to time Financial Institution may 
amend any of the terms and conditions contained in this Agreement, 
including without limitation, any cut-off time, any business day, and 
any part of Schedules A through E attached hereto. Such amendments 
shall become effective upon receipt of notice by Company or such later 
date as may be stated in Financial Institution's notice to Company. 



19. 



Notices, Instructions, Etc. 



(a) Except as otherwise expressly provided herein, Financial 

Institution shall not be required to act upon any notice or instruction 
received from Company or any other person, or to provide any notice or 
advice to Company or any other person with respect to any matter. 



(b) Financial Institution shall be entitled to rely on any written notice 
or other written communication believed by it in good faith to be 
genuine and to have been signed by an Authorized Representative, and 
any such communication shall be deemed to have been signed by such 
person. The names and signatures of Authorized Representatives are set 
forth in Schedule F attached hereto. Company may add or delete any 
Authorized Representative by written notice to Financial Institution 
signed by at least two Authorized Representatives other than that being 
added or deleted. Such notice shall be effective on the [e.g., second 
business day] following the day of Financial Institution's receipt thereof. 

(c) Except as otherwise expressly provided herein, any written notice 
or other written communication required or permitted to be given under 
this Agreement shall be delivered, or sent by United States registered or 
certified mail, postage prepaid, or by express carrier, and, if to Financial 
Institution, addressed to: 



Attn: 



and, if to Company, addressed to: 



Attn: 



unless another address is substituted by notice delivered or sent as 
provided herein. Except as otherwise expressly provided herein, any 
such notice shall be deemed given when received. 

20. Data Retention . Company shall retain data on file adequate to 
permit remaking of Entries for : days following the date of their 
transmittal by Financial Institution as provided herein, and shall provide 
such Data to Financial Institution upon its request. 

21. Tapes and Records . AH magnetic tapes, Entries, security 
procedures and related records used by Financial Institution for 
transactions contemplated by this Agreement shall be and remain 
Financial Institution's property. Financial Institution may, at its sole 
discretion, make available such information upon Company's request. 
Any expenses incurred by Financial Institution in making such 
information available to Company shall be paid by Company. 

22. Evidence of Authorization . Company shall obtain all consents 
and authorizations required under the Rules and shall retain such 
consents and authorizations for two years after they expire. 

23 . Cooperation in Loss Recovery Efforts . In the event of any 
damages for which Financial Institution or Company may be liable to 
each other or to a third party pursuant to the services provided under 
this Agreement, Financial Institution and Company will undertake 
reasonable efforts to cooperate with each other, as permitted by 
applicable law, in performing loss recovery efforts and in connection 
with any actions that the relevant party may be obligated to defend or 
elects to pursue against a third party, 

24. Termination . Company may terminate this Agreement at any 
time. Such termination shall be effective on the [e.g., second business 
day] following the day of Financial Institution's receipt of written notice 
of such termination or such later date as is specified in that notice. 
Financial Institution reserves the right to terminate this Agreement 
immediately upon providing written notice of such termination to 
Company. Any termination of this Agreement shall not affect any of 
Financial Institution's rights and Company's obligations with respect to 
Entries initiated by Company prior to such termination, or the payment 
obligations of Company with respect to services performed by Financial 
Institution prior to termination, or any other obligations that survive 
termination of this Agreement. 

25. Entire Agreement . This Agreement (including the Schedules 
attached hereto), together with the Account Agreement, is the complete 
and exclusive statement of the agreement between Financial Institution 
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and Company with respect to the subject matter hereof and supersedes 
any prior agreement(s) between Financial Institution and Company with 
respect to such subject matter. In the event of any inconsistency 
between the terms of this Agreement and the Account Agreement, the 
terms of this Agreement shall govern. In the event performance of the 
services provided herein in accordance with the terms of this Agreement 
would result in a violation of any present or future statute, regulation or 
government policy to which Financial Institution is subject, and which 
governs or affects the transactions contemplated by this Agreement, 
then this Agreement shall be deemed amended to the extent necessary 
to comply with such statute, regulation or policy, and Financial 
Institution shall incur no liability to Company as a result of such 
violation or amendment. No course of dealing between Financial 
Institution and Company will constitute a modification of this 
Agreement, the Rules, or the security procedures or constitute an 
agreement between the Financial Institution and Company regardless of 
whatever practices and procedures Financial Institution and Company 
may use.- .'■■'.■.'.'■.■.'■■■.■■.■:'■;■■'■.'■■ , : '.-.■'...'■. -. : . ...'.'.'.; -^ .■ . 

26. Non-Assignment . Company may not assign this Agreement or 
any of the rights or duties hereunder to any person without Financial 
Institution's prior written consent. 

27- Waiver . Financial Institution may waive enforcement of any 
provision of this Agreement Any such waiver shall not affect Financial 
Institution's rights with respect to any other transaction or modify the 
terms of this Agreement. 

28. Binding Agreement; Benefit . This Agreement shall be binding- 
upon and inure to the benefit of the parties hereto and their respective 
legal representatives, successors and assigns. This Agreement is not for 
the benefit of any other person, and no other person shall have any right 
against Financial Institution or Company hereunder. 

29. Headings . Headings are used for reference purposes only and 
shall not be deemed a part of this Agreement. 

30. Severability . In the event that any provision of this Agreement 
shall be determined to be invalid, illegal or unenforceable to any extent, 
the remainder of this Agreement shall not be impaired or otherwise 
affected and shall continue to be valid and enforceable to the fullest 
extent permitted by law. 

31. Governing Law . This Agreement shall be construed in 
accordance with and governed by the laws of the State of 



IN WITNESS WHEREOF the parties hereto have caused this 
Agreement to be executed by their duly authorized officers. 



Financial Institution 



Company 



By_ 

Name 
Title 



_By_ 

Name 
"Title 



3. RELATIONSHIP WITH RECEIVER 

For the majority of consumer applications, the Receiver 
authorizes the Originator to initiate entries through the 
ACH Network to the Receiver's account. The 
authorization agreement must be readily identifiable as 
either an ACH credit or an ACH debit authorization and 
must clearly and conspicuously state the terms of the 
authorization in order that the Receiver understands the 
authorization to which he is agreeing. The type of 
arrangement entered into between the Receiver and the 



Originator depends upon the type of application that is 
being initiated. Corporate applications, where the 
Originator and Receiver have entered into a trading 
partner agreement, could require more intricate 
agreements than consumer applications because the 
application could include the processing of payment 
related data or because the application necessitates the 
transfer of large dollars. 

Authorization Requirements for Consumer Applications 

Included within this section are sample Authorization 
Agreements for Direct Deposits (Credits) and Direct 
Payments (Debits) in consumer applications. 

The following general direction is offered to promote 
accuracy and standardization for authorization 
requirements: 

• Account numbers and routing numbers must be 
accurately stated. 

Originators may use the on-us Field of the MICR line of 
checks and sharedrafts to obtain the account number for 
ACH transactions. Originators must ensure, and, under 
the requirements of the Rules, ODFIs are required to 
warrant that the correct Receiver's account number is 
contained within each ACH entry. Originators are 
strongly encouraged to establish practices and 
procedures to ensure the validity and accuracy of each 
Receiver' s account number for all entries transmitted 
into the Network. 

Originators should also look on the face of a check or 
sharedraft for the routing information. Some financial 
institutions may print the Routing Number and account 
number used for ACH purposes on the face of the 
document if the information on the MICR line is not 
appropriate for ACH activity. In addition, some 
financial institutions may provide their customers with 
another source document that indicates the routing and 
account number to be used for ACH entries. 

In an effort to help ensure the proper routing and 
processing of ACH transactions, Originators should 
consider the implementation of practices and 
procedures that will enable them to verify the accuracy 
of routing numbers prior to me transmission of entries 
into the ACH Network. Originators must be aware that, 
in certain circumstances, such as with TEL entries and 
WEB entries, theA^ CHA Operating Rules specifically 
require an Originator to establish commercially 
reasonable procedures to verify that routing numbers 
are valid. 

.•' The consumer must date and either sign or similarly 
authenticate a written authorization. 




When the authorization is directed to a demand deposit 
account or a savings account, the authorizer(s) should 
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so indicate. NOW accounts and sharedraft accounts are 
transaction accounts within the broad category of 
demand accounts. The authorizer(s) will also need to 
indicate when the authorization relates to entries 
directed to a loan account. 

• The company identification number is agreed upon by 
the originating company and the ODFI. It is common 
practice to use one of the ANSI standard identifiers 
indicating what type of number is used. The ANSI 
standard identifiers are: "1" (indicating an IRS 
number) ; "3 " (indicating a DUNS number) ; or "9" 
(indicating a user-assigned number). 

• The individual ID number is the number assigned by an 
Originator for internal control: Social Security number, 
employee number, customer billing number, or 
customer internal account number. No more than 15 
characters of identification can be used for this purpose. 
(Spaces and dashes are included in the count of 15.) 

• The Originator must obtain authorization for both 
consumer credit and debit entries. An exception to the 
credit authorization requirement occurs when both the 
Originator and Receiver are natural persons. 

Credits 



Authorizations for credit entries may be provided by the 
consumer in writing, or they may be provided orally or by 
other non- written means. 

Debits 

All debits to consumer accounts must be authorized by the 
consumer via a writing that is signed or similarly 
authenticated by the consumer, with the exception of ARC 
entries, RCK entries, and TEL entries. 

Originators of debit entries to consumer accounts must 
ensure compliance with the following criteria to ensure 
proper authorization of consumer debits under the 
NACHA Operating Rules: 

• Copy of Authorization — With the exception of ARC 
entries, TEL entries, and RCK entries, the Originator 
must send to the consumer written authorization. This 
authorization may be sent by mail, fax, or Internet/on- 
line network, or it may be provided to the consumer in 
person. In circumstances where the consumer signs the 
written authorization or, alternatively, uses the 
telephone to similarly authenticate the written 
authorization by speaking or key entering a code 
provided to the consumer on the written authorization, 
the consumer has a paper authorization in his 
possession, which he should retain as his copy of the 
authorization. The consumer can also request an 
additional hard copy of the authorization from the 
Originator. For the Internet/on-line network 
alternative, the consumer reads the authorization that is 



displayed on the computer screen or other visual 
display. The consumer should print the authorization 
from his computer screen and retain this copy. The 
Originator must be able to provide the consumer with 
a hard copy of the authorization if requested to do so. 

For TEL entries, the consumer ' s authorization may be 
obtained orally via the telephone for Single Entry debits 
where there is (1) .an Existing Relationship between the 
Originator and the consumer or (2) no Existing 
Relationship between the Originator and the consumer, 
but the consumer has initiated the telephone call to the 
Originator. The Originator must either tape record the 
authorization or provide the Receiver with written 
notice confirming the oral authorization prior to the 
Settlement Date of the entry. At the request of the 
ODFI, the Originator must be able to provide a copy of 
the written notice or duplicate tape recording of the oral 
authorization to the ODFI for its use or for the use of 
the RDFI requesting the information. 

For ARC entries and RCK entries, authorization 
consists of notice from the Originator to the consumer 
and the receipt of the consumer ' s source document (for 
ARC entries) or item (for RCK entries) by the 
Originator. 

Minimum Information Requirements .-. The 
authorization must be readily identifiable as an ACH 
debit authorization and must clearly and conspicuously 
state its terms. With the exception of POP entries, TEL 
entries, and Single-Entry WEB entries, the writing must 
specify that the Receiver may revoke the authorization 
only by notifying the Originator in the manner specified 
on the authorization form. 

► For TEL entries, where the consumer's authorization 
is obtained orally via the telephone, the authorization 
must be readily identifiable as an authorization and 
must clearly state its terms. The following minimum 
information must be included as part of the 
authorization: 

the date on or after which the ACH debit to 
the Receiver's account will occur; 
■ ■ - the amount of the transaction; 

. - '■; the Receiver's name; 
■ . . - ■ a telephone number for Receiver inquiries that 
is answered during normal business hours; 
- ■ . the date of the Receiver's oral authorization; 

and 
■-■;': a statement by the Originator that the 

authorization obtained from the Receiver is 
for a Single-Entry ACH debit. 



Authentication of Authorization - With the exception 
of ARC entries, RCK entries, and TEL entries, the 
written authorization must be signed or similarly 
authenticated by the consumer. Figure 4 (Guidelines 
for Similarly Authenticated) outlines acceptable 
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alternatives for authenticating the consumer's 
authorization. 

Similarly Authenticated 

The similarly authenticated standard permits signed, 
written authorizations to be provided electronically. 
These writing and signature requirements are satisfied 
by compliance with the Electronic Signatures in Global 
and National Commerce Act (15 U.S. C. 7001 et seq.), 
which defines electronic records and electronic 
signatures. Electronic records include contracts or 
other records created, generated, sent, communicated, 
received, or stored by electronic means. Electronic 
signatures include, but are not limited to, digital 
signatures and security codes. 

To satisfy the requirements of Regulation E and the 
NACHA Operating Rules, the authentication method 
chosen must evidence both the consumer's identity and 
his assent to the authorization. 

Examples of methods used to similarly authenticate an 
authorization include, but are not limited to, the use of 
digital signatures, codes, shared secrets, PINs, etc. It is 
important to note that the authorization and the 
authentication of that authorization must occur 
simultaneously. It is not considered acceptable 
authentication to have identified a consumer at the time 
of logging on to a website and then later consider that 
log-in as an authentication for purposes of authorizing 
an ACH debit. Nor is it considered acceptable to 
authenticate an authorization on a website simply by a 
click-through process. 

' Retention of Authorization - The signed or similarly 
authenticated authorization must be retained by the 
Originator for a period of two years following the 
termination or revocation of the authorization. In the 
case of a paper authorization that has been signed by 
the consumer, the Originator must retain either the 
original or a microfilm-equivalent copy of the signed 
authorization. In the case of an authentication made via 
telephone, the Internet, or other on-line network, the 
Originator must retain a copy of the authorization and 
a recorded record of the authentication. For TEL 
entries, the Originator must retain a copy of the tape 
recorded authorization or a copy of the written notice 
confirming the authorization for a period of two years 
from the date of the authorization. Authorization may 
be retained as an electronic record that (I) accurately 
reflects the information in the record, and (2) is capable 
of being accurately reproduced for later reference, 
whether by transmission, printing, or otherwise. 

Multiple, Non-Recurring Debits 

For multiple but non-recurring debits, where the amount 
and time frame for the initiation of the debits may vary 
(for example, occasional catalog purchases from the same 



merchant or occasional purchases of securities with a 
broker), Originators need not obtain a written 
authorization for each debit entry, provided they have 
obtained a written authorization up front which establishes 
a relationship between the Originator and Receiver 
(consumer) for this type of activity. 

Notice of Change in Amount/Change in Debiting Date for 
Recurring Debits 

For recurring debits, when the debit amount varies, 
specific requirements apply. If a preauthorized debit 
transfer varies from a previous transfer relating to the 
same authorization or from a fixed preauthorized amount, 
the Originator must send the Receiver written notification 
of the amount and scheduled date of the transfer at least 
ten (10) calendar days before the scheduled transfer date. 
Additionally, if the Originator informs the consumer of 
the right to receive notice of all varying transfers, the 
consumer may elect to receive notice only when a transfer 
does not fall within a specified range of amounts; or, 
alternatively, the consumer may elect to receive notice 
only when a transfer differs from the most recent transfer 
by more than an agreed upon amount. 

In an application in which the Originator changes the date 
on or after which a recurring debit entry is scheduled to be 
debited to a Receiver's account, the Originator must send 
the Receiver written notification of the new date on which 
the entry will he debited at least seven (7) calendar days 
before the first entry to be affected by the change is 
scheduled to be debited to the Receiver's account. 

Consumer Information 

Originators must ensure that the consumer is completely 
aware of the nature of the product or service that he or she 
is purchasing. The rights provided to the consumer in 
questioning electronic funds transfer activity to his 
account are very liberal. Failure to understand the nature 
of the product or service that is being sold could result in 
the return of the ACH debit to the Originator. 

Information Requirements 

The Originator, upon request, must present a copy of the 
customer's authorization to an ODFI for use by the RDFL 
The RDFI should not ask for the customer authorization 
as a normal course of business but only if an exception is 
expected or has occurred. 

Revocation of Authorization 

A Receiver wishing to cancel or revoke his or her 
authorization must do so directly with the Originator 
under the terms and conditions set forth in the 
authorization agreement. A consumer may inform its 
RDFI that it has revoked an authorization, thereby causing 
an entry to be returned to the Originator. Before an RDFI 
may return an entry for "Authorization Revoked by 
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Customer" (return reason code R07), the RDFI must 
obtain from the Receiver a written statement under 
penalty of perjury, in which the Receiver states that the 
authorization for the debit entry has been revoked directly 
with the Originator. (Note: At its discretion, the RDFI 
can still choose to require that an affidavit be signed.) 
The Originator may request that its ODFI obtain a copy of 
the written statement under penalty of perjury from the 
RDFI when appropriate. A written request for a copy of 
the written statement under penalty of perjury must be 
received by the RDFI within one year of the date on which 
the adjustment entry was initiated by the RDFI. The 
RDFI is required to provide a copy of the written 
statement under penalty of perjury within sixty days after 
receiving the ODFI's written request for the copy. (A 
sample written statement under penalty of perjury may be 
found in the chapter concerning Receiving Depository 
Financial Institutions in Section II of these Guidelines.) 
Originators may not reinitiate entries returned for 
authorization revoked and should be prepared to contact 
the Receiver regarding those entries. (Note: POP entries, 
TEL entries, and Single-Entry WEB Entries may not be 
returned by an RDFI as "Authorization Revoked." 
Because these transactions are one-time payments where 
the Originator will generally process the transaction 
immediately after the purchase is complete, the Receiver 
is precluded from revoking authorization for the 
transaction. The Receiver does, however, retain his right 
to place a stop payment order on such transactions and to 
request the return of any unauthorized entry.) 

Unauthorized/Improper Consumer Debits 

Unauthorized Consumer Debit Entries 

Originators can expect the return of entries that were not 
properly authorized. An unauthorized debit entry is an 
entry in which: 

• the written authorization requirements have not been 
followed; 

• a transaction was initiated in an amount greater than 
that authorized by the Receiver; 

• a transaction was initiated for settlement earlier than 
authorized by the Receiver; or 

• with respect to ARC entries, (1) notice was not 
provided to the Receiver by the Originator in 
accordance with the requirements of the NACHA 
Operating Rules, (2) the entry was transmitted to an 
account of a Receiver who opted out of ARC check 
conversion activity, or (3) the amount of the ARC entry 
was not accurately obtained from the source document. 

Consumer debit entries returned by the RDFI as 
unauthorized will bear Return Reason Code RIO 
(Customer Advises Not Authorized, Notice Not Provided, 
Improper Source Document, or Amount of Entry Not 



Accurately Obtained from Source Document) and must be 
returned by the RDFI in such time and manner that the 
return is made available to the ODFI no later than the 
opening of business on the banking day following the 
sixtieth calendar day following the Settlement Date of the 
original entry. This return deadline also applies to debit 
entries for which the consumer Receiver had previously 
revoked his authorization for the transaction (Return 
Reason Code R07 - Authorization Revoked) . 

At times, Originators may erroneously transmit ACH 
entries that are formatted using an incorrect SEC Code. 
This is in violation of the NACHA Operating Rules. 
Because the Rules require the RDFI to rely on the ODFFs 
warranty that the SEC Code included in the entry is 
proper, the RDFI is obligated to use the return rules and 
time frames associated with that particular SEC Code. 
Currently, an unauthorized debit to a consumer account 
where that entry incorrectly bears a corporate SEC Code 
must be returned in accordance with the return rules and 
time frames governing corporate transactions (that is, 
using Return Reason Code R29 within two banking days 
of the Settlement Date of the original entry). In such 
cases, the RDFI is typically precluded from automatically 
returning such an unauthorized debit because the return 
time frame for corporate entries will have lapsed before 
the consumer can receive his statement and notify his 
RDFI about the unauthorized debit to his account. 
Instead, the RDFI would be required to request 
permission from the ODFI to return the entry as a 
permissible return. 

Effective March 18, 2005, a new Return Reason Code 
R05 (Unauthorized Debit to Consumer Account Using 
Corporate SEC Code) will become available to RDFIs for 
the return of unauthorized debits transmitted to consumer 
accounts when those debit entries incorrectly bear a 
corporate SEC Code (i.e., CCD, CTX, or CBR). With the 
addition of this rule, the RDFI will be permitted to return 
all unauthorized debits to consumer accounts, regardless 
of SEC Code, within sixty days of the Settlement Date of 
the original entry, provided the RDFI has obtained a 
written statement under penalty of perjury from the 
consumer. 

Ineligible/Improper Consumer Debit Entries 

Originators may also expect the return of entries that were 
ineligible for ACH origination or that were originated 
improperly. An ineligible or improper debit entry is an 
entry for which: 

• Ineligible RCK Entries: 

- the item to which the entry relates is ineligible to 
be initiated as an RCK entry (Return Reason Code 
R51); 

- the required notice stating the terms of the re- 
presented check entry policy was not provided by 
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the Originator in accordance with the requirements 
of the NACHA Operating Rules (Return Reason 
CodeRSl); 

all signatures on the item to which the RCK entry 
relates are not authentic or authorized, or the item 
has been altered (Return Reason Code R51); 

the amount of the RCK entry was not accurately 
obtained from the item (Return Reason Code 
R51);or 



- both the RCK entry and the item to which the 
RCK entry relates have been presented for 
payment (Return Reason Code R53). 

Improper ARC Entries: 

- the source document used for the debit entry is 
improper (Return Reason Code RIO): 

-'. checks drawn on corporate or business 
accounts; 

- third-party checks; 

- demand drafts/third-party drafts that do not 
contain the signature of the Receiver; 

- credit card checks; 

- obligations of a financial institution (travelers 
checks, cashier's checks, official checks, money 
orders, etc.) 

- checks drawn on the U.S. Treasury, a Federal 
Reserve Bank, or a Federal Home Loan Bank; 

- checks drawn on a state or local government; 

- checks payable in a medium other than United 
States currency. 

- the source document was presented for payment 
(Return Reason Code R37). 

Ineligible POP Entries: 

-■■■'. the source document used for the debit entry is 
improper (Return Reason Code RIO): 

- checks drawn on corporate or business accounts; 
'..- third-party checks; 

.'..'■ V credit card checks; 

- obligations of a financial institution (travelers 
checks, cashier's checks, official checks, money 
orders, etc.) 

- checks drawn on the U.S. Treasury, a Federal 
Reserve Bank, or a Federal Home Loan Bank; 

- checks drawn on a state or local government; 

- checks payable in a medium other than United 
States currency; 

- previously voided checks/sharedrafts used for 
prior POP entries. 

the source document was presented for payment 
(Return Reason Code R3 7). 



Originators receiving returns for Return Reason Codes 
R05 (effective March 18, 2005), RIO, R37, R51, andR53 
should be aware that the RDFI is warranting that it has 
obtained a written statement under penalty of perjury from 
the consumer in which the consumer states that the debit 
entry being returned was not authorized or is 
ineligible/improper. The procedures for obtaining a copy 
of the written statement under penalty of perjury are the 
same as previously discussed in the section on Revocation 
of Authorization. 

Agreements for Corporate Transactions 

The nature of the agreement for corporate transactions can 
vary depending upon the complexity of the application 
and the relationship between the Originator and the 
Receiver. The Originator that is collecting or disbursing 
funds to its own subsidiaries, for example, may require an 
entirely different agreement for the funds transfer than it 
would if it were entering into a trading partner agreement 
with another corporation. 

Remittance Information/Zero Dollar Entries 




The nature of the agreement will also most likely be 
different if the application includes the processing of 
payment-related data along with the payment. 

Zero Dollar entries are entries that carry no settlement 
value but do include payment-related remittance data. 
Examples of zero dollar entries include CTX and CCD 
entries that carry remittance information indicating a 
credit position of the Originator to the Receiver or relating 
to a period of time during which no funds are owed by the 
Originator to the Receiver. Originators must ensure that 
corporate trading partner agreements include provisions 
for remittance data to be sent via the ACH Network for 
either live dollar or zero dollar entries. 

Corporate Debits 

Originators of corporate debits to Receivers other than 
their own subsidiaries need to be aware of the sensitivity 
of this application. Many corporate Receivers are 
reluctant to allow debit activity to their accounts; 
therefore, it is imperative that the agreement that supports 
this type of activity is complete and accurate. Originators 
may be required to provide some proof that debit activity 
was, in fact, authorized if a transaction is questioned by 
the Receiver. 
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AUTHORIZATION AGREEMENT FOR DIRECT DEPOSITS (ACH CREDITS) 

Company Company 

Name ID Number 



I (we) hereby authorize , hereinafter called COMPANY, to initiate credit 

entries to my (our) O Checking Account / a Savings Account (select one) indicated below at the depository financial institution named below, 
hereafter called DEPOSITORY, and to credit the same to such account. I (we) acknowledge that the origination of ACH transactions to my (our) 
account must comply with the provisions of U.S. law. 

Depository 

Name Branch 



City ■■-.'■.•■■■.•■■■■■■■ ......... v .•..;.:■-. .•. '■•.:.■. ■ ■ . ■ ■ State Zip_ 

Routing Account : 

Number Numbe r , 



This authorization is to remain in full force and effect until COMPANY has received written notification from me (or either of us) of its 
termination in such time and in such manner as to afford COMPANY and DEPOSITORY a reasonable opportunity to act on it. 

Name(s ) ID Numbe r __ 

(Please Print) 

Date Signature___ _____ _____ ______ 



NOTE: WRITTEN CREDIT AUTHORIZATIONS MUST PROVIDE THAT THE RECEIVER MAY REVOKE THE 
AUTHORIZATION ONLY BY NOTIFYING THE ORIGIN ATOR IN THE MANNER SPECIFIED IN THE AUTHORIZATION. 



Figure 2 - Credit Authorization 



AUTHORIZATION AGREEMENT FOR DIRECT PAYMENTS (ACH DEBITS) 

Company Company 

Name ■::■■:•■■■•■■'■:■:■;■-■ ■'■• ■ ■ . ■ • -.v.- .•■.■■.:■:.■■■■ ' '. id Numbe r 



I (we) hereby authorize ■'.■'■'■'■'■:■'■■'■'■-■'■'■■■■■:■:■'■'■'■■■'■'■'■'■'■'■: ' ■ ":'■'■'■'.'■'■■: : , hereinafter called COMPANY, to initiate debit 

entries to my (our) a Checking Account / a. Savings Account (select one) indicated below at the depository financial institution named below, 
hereafter called DEPOSITORY, and to debit the same to such account. I (we) acknowledge that the origination of ACH transactions to my (our) 
account must comply with the provisions of U.S. law. 

Depository 

Name Branch 



■City ' ■ ■ : ■ ■ ■ ■ :■■■■■■■•■■■■.■•■ • -V : : :.-■•.■;■:■■:■•.■■■■:■- ■ ■ State Zip_ 

Routing Account 

Number Numbe r 



This authorization is to remain in full force and effect until COMPANY has received written notification from me (or either of us) of its 
termination in such time and in such manner as to afford COMPANY and DEPOSITORY a reasonable opportunity to act on it. 



Name(s) IDNumbe r 

(Please Print) 

Date _______ Signatur e 

NOTE: DEBIT AUTHORIZATIONS MUST PROVIDE THAT THE RECEIVER MAY REVOKE THE AUTHORIZATION ONLY 
BY NOTIFYING THE ORIGINATOR IN THE MANNER SPECIFIED IN THE AUTHORIZATION. 



Figure 3 - Debit Authorization 
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Figure 4 - Guidelines for Similarly Authenticated 
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C. ACKNOWLEDGMENT ENTRIES 

Originators may request an acknowledgment by the RDFI 
that a corporate credit payment (CCD or CTX entry) has 
been received by the RDFL ACH Acknowledgment 
entries are optional, non-dollar transactions that may be 
used by an RDFI to acknowledge that a corporate ACH 
credit entry has been received and that the RDFI will 
attempt to post the payment to the Receiver's account. 
The ACK and ATX Standard Entry Class Codes provide 
the platform for state and Federal Government agencies 
and other corporate users to utilize the ACH Network for 
acknowledgment purposes. For detailed information on 
how to utilize the ACH Acknowledgment process, see the 
Acknowledgment Entries chapter in these Guidelines. 

D. AUTOMATED ENROLLMENT 

The Automated Enrollment (ENR) entry is an optional, 
non-dollar transaction that may be used by a depository 
financial institution to transmit enrollment information for 
both ACH credit and debit applications on behalf of the 
DFI's customer to a Federal Government Agency that 
accepts Automated Enrollment entries. For detailed 
information on originating Automated Enrollment entries, 
refer to the chapter on Automated Enrollment Entries 
within Section IV of these Guidelines. 

E. CROSS-BORDER ENTRIES 

The CBR and PBR Standard Entry Class Codes must be 
used by Originators to transmit cross-border ACH credit 
and debit entries. The CBR Standard Entry Class Code is 
used for the transmission of corporate cross-border 
entries, and the PBR Standard Entry Class Code is used 
for the transmission of consumer cross-border 
transactions. These Standard Entry Class Codes allow 
cross-border transactions to be readily identified by 
financial institutions so that they may apply special 
handling requirements for cross-border payments, as 
desired. These formats enable ACH participants to 
transmit and receive detailed information that is unique to 
cross-border payments. 

The cross-border formats utilize a unique Company/Batch 
Header Record to convey information relating to foreign 
exchange, origination and destination currencies, and 
destination country. Each CBR and PBR Entry Detail 
Record is accompanied by one mandatory addenda 
record, within which information relating to the foreign 
receiving DFI, foreign payment amount, foreign trace 
number, and foreign receiver's account number is 
conveyed. 

For CBR and PBR return entries, unique Company/Batch 
Header Records and Addenda Records accommodate the 
return of cross-border-specific information. The Entry 
Detail Record used for cross-border returns is the same 
format used for all other returns but has been expanded to 
accommodate cross-border information. 



A unique Company/Batch Header Record accommodates 
cross-border dishonored returns, contested dishonored 
returns, NOCs, and refused NOCs. The existing Entry 
Detail Records and Addenda Records for dishonored 
returns, contested dishonored returns, NOCs, and refused 
NOCs have been expanded to accommodate cross-border 
payments. 

For additional information relating to the origination of 
Cross-Border Payments, refer to the Cross-Border 
Payments chapter within Section IV of these Guidelines. 
For specific information on formatting requirements and 
technical specifications associated with the CBR and PBR 
Standard Entry Class Codes, refer to the NACHA 
Operating Rules . 

F. POINT-QF-PURCHASE ENTRIES 

A Point-Of-Purchase entry (POP) is a Single-Entry ACH 
debit entry, initiated by an Originator (i.e.; a merchant, 
biller, etc.) to a consumer's account for the in-person 
payment for goods or services. These one-time debit 
entries are initiated by the Originator based on a written 
authorization and account information drawn from a 
source document (check) obtained from the consumer at 
the point-of-purchase. The source document, which is 
voided by the merchant and returned to the consumer at 
the point-of-purchase, is used to obtain the consumer's 
routing number, account number, and check serial number 
that will be used to generate the debit entry to the 
consumer's account. For detailed information on 
originating Point-of-Purchase entries, refer to the Point- 
of-Purchase Entries chapter within Section IV of these 
Guidelines. 

C RE-PRESENTED CHECK ENTRIES 

A Re-presented Check Entry (RCK) is a Single-Entry 
ACH debit entry used by Originators (merchants, billers, 
etc.) as an alternative method of collecting checks that 
have been returned because of insufficient or uncollected 
funds. This method of collection via the ACH Network, 
when compared to the check collection process, provides 
Originators with the potential for improvements to 
processing efficiency (such as control over timing of the 
initiation of the debit entries) and decreased costs. For 
detailed information on RCK entries, refer to the chapter 
on Re-presented Check Entries within Section IV of these 

Guidelines. 

H ACCOUNTS RECEIVABLE ENTRIES 

An Accounts Receivable (ARC) Entry is a Single-Entry 
ACH debit used by Originators (i.e., merchants, billers, 
etc.) to convert a consumer check that is received via the 
U.S. mail or at a dropbox location for the payment of 
goods or services. These one-time debit entries are 
initiated by the Originator based on a notice provided to 
the Receiver by the Originator, clearly and conspicuously 
stating that the receipt of the source document will 
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authorize an ACH debit entry to the Receiver ' s account in 
accordance with the terms of the source document. Debit 
entries are initiated by the Originator based on payment 
information (the consumer's routing number, account 
number, check serial number, and dollar amount for the 
transaction) drawn from the consumer's source document. 
For detailed information on Accounts Receivable Entries, 
see Section IV of these Guidelines. 

L INTERNET-INITIATED ENTRIES 

Originators initiating debit entries (both recurring and 
Single-Entry) to a consumer account pursuant to an 
authorization that is obtained from the Receiver via the 
Internet are required to utilize the WEB (Internet-Initiated 
Entry) Standard Entry Class Code. This SEC Code is 
intended to address unique risk issues that are inherent to 
the Internet payment environment through requirements 
for added security procedures and obligations. For 
detailed information on originating WEB entries, refer to 
the chapter on Internet-Initiated Entries within Section IV 
of these Guidelines. 

J. TELEPHONE-INITIATED ENTRIES 

Originators of Single-Entry debits to consumer accounts 
may obtain an oral authorization for such an entry from 
the consumer via the telephone. These Single-Entry 
debits, which must utilize the TEL Standard Entry Class 
Code, may only be originated when either (1) there is an 
existing relationship between the Originator and the 
Receiver, or (2) there is no existing relationship between 
the Originator and the Receiver, but the Receiver has 
initiated the telephone call. For detailed information on 
originating TEL entries, refer to the chapter entitled 
Telephone-Initiated Entries within Section IV of these 
Guidelines. 



K. PRENOTIFICATION 

A prenotification entry is an optional, non-dollar 
transaction that may be used by an Originator to verify 
that the account number on an entry is for a valid account 
at an RDFI. For complete instructions on originating 
prenotification entries, refer to the Prenotification chapter 
within Section III of these Guidelines. 

L. PROCESSING REQUIREMENTS AND 
RESPONSIBILITIES 

1. TRANSACTION CODES 

The NACHA Operating Rules permit Originators to 
transmit ACH credit and debit entries to demand accounts 
(i.e., checking, NOW, and sharedra ft accounts) and 
savings accounts at an RDFI. The NACHA Operating 
Rules also permit Originators to transmit both credit and 
debit entries to financial institutions' general ledger and 
to transmit credit entries only (with the exception of 



reversing debits to correct erroneous credits) to loan 
accounts. 

6 Financial Institution General Ledger Accounts ™ 
Originators may transmit both ACH credit and debit 
entries to financial institutions' general ledger accounts. 
These entries are corporate transactions and must be 
properly authorized in accordance with the 
requirements of the NACHA Operating Rules. An 
Originator may not transmit an entry to a financial 
institution's general ledger account unless it has been 
authorized by an agreement with the financial 
institution. Originators will need to work closely with 
RDFIs (i.e., the corporate Receivers of general ledger 
transactions) to ensure that they have obtained 
appropriate routing and account number information 
regarding the general ledger account to which the 
transaction will be transmitted. 

* Loan Accounts — Originators may transmit ACH credit 
entries to loan accounts belonging to a Receiver. 
Examples of applications for which entries could be 
transmitted to loan accounts include consumer loan 
payments, corporate loan payments, and salary 
allotments . Originators must be aware that, with the 
exception of reversals to correct erroneous credits, 
debit entries to loan accounts are prohibited. The ACH 
Operators have established edits that cause any debit to 
a loan account which does not contain the word 

"REVERSAL" in the Company Entry Description field 
to reject and be returned to the ODFI. 

Source documents that are currently used to obtain the 
routing and account information for demand and savings 
accounts (for example, a voided check or sharedraft) are 
not available for use with loan or general ledger accounts. 
For such entries, Originators must rely on other 
documentation provided by the Receiver, such as a credit 
card account statement, loan account statement, or coupon 
book, to obtain loan account information. Originators 
must provide ODFIs or Third-Party Service Providers 
with information relating to the types of accounts to which 
these entries will be directed. 

Originators should be aware that the NACHA Operating 
R ules permit an RDFI to return any entry that concerns an 
account that is not a "transaction account" as defined by 
Regulation D of the Board of Governors of the Federal 
Reserve System. Because loan accounts and general 
ledger accounts do not fall within the Regulation D 
definition of a "transaction account," an RDFI may 
exercise its right to return any payment directed to these 
accounts using Return Reason Code R20 (Non- 
Transaction Account), provided the return entry complies 
with all rules governing return entries. 
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2. ACH DATA SECURITY REQUIREMENTS 

Data Security 

For all ACH transactions that involve the exchange or 
transmission of banking information (which includes, but 
is not limited to, an entry, entry data, a routing number, an 
account number, and a PIN or other identification symbol) 
via an Unsecured Electronic Network, the NACHA 
Operating Rules impose specific data security 
requirements for those ACH transactions, regardless of 
the SEC Code contained within the entry. An Unsecured 
Electronic Network is a public or private network that is 
not located entirely within a single, contiguous, physical 
facility and any part of which that has not implemented 
security technologies that provide a level of security that, 
at a minimum, is equivalent to 128-bit RC4 encryption 
technology. 

Specifically, this rule requires any banking information 
that is transmitted or exchanged via an Unsecured 
Electronic Network to be either (1) encrypted using a 
commercially reasonable security technology that, at a 
minimum, is equivalent to 128-bit RC4 encryption 
technology, or (2) transmitted via a secure session that 
utilizes a commercially reasonable security technology 
that provides a level of security that, at a mmimum, is 
equivalent to 128-bit RC4 encryption technology. Such 
encryption technology must be employed prior to the key- 
entry and through the transmission of any banking 
information exchanged, via an Unsecured Electronic 
Network, between ( 1 ) an Originator and a Receiver; (2) an 
Originator and an ODFI; (3) an GDFI and an ACH 
Operator; (4) an ACH Operator and an RDFI; and (5) an 
Originator, ODFI, RDFI, or ACH Operator and a Third- 
Party Service Provider. 



Transmissions or exchanges of banking information using 
voice or keypad inputs from a wireline or wireless 
telephone are not subject to this data security requirement 
unless the telephone is used to access the Internet. An 
application in which the Originator obtains information 
from the Receiver by another means (such as the 
telephone) and then key enters the information via the 
Internet would, for example, be subject to these data 
security requirements. However, information delivered 
via a telephone line, such as a leased line, ordialed into a 
financial institution's modem pool wouldnot be subject to 
this requirement. 

Verification of Identity of Originators 

This rule also requires ODFIs to utilize commercially 
reasonable methods to establish the identity of each 
Originator that uses an Unsecured Electronic Network, 
such as the Internet, to enter into a contractual relationship 
with the ODFI for the origination of ACH transactions. 
Such a requirement helps to ensure that ODFIs employ 
measures to know the Originators with whom they 



establish relationships over Unsecured Electronic 
Networks and to verify those Originators' identities. 

3. RELATIONSHIP WITH ODFI 

The ODFI and the Originator must mumally detenrnne 
how the payment information will flow from the 
Originator into the ACH Network and what the role of the 
ODFI will be regarding the processing of that information. 
The role of the ODFI will vary depending on the 
following: 

■ • the level of sophistication of the ODFI and the 
Originator in processing ACH entries; 

• the ability of the Originator to generate the payment 
information in ACH format; 

• the nature of the payment application; 

• the policy of the ODFI regarding the use of a Third- 
Party Service Provider; 

• the policy of the ODFI regarding the use of Sending 
Points other than the ODFI; and 

• the involvement of Third-Party Senders in the 
origination of ACH entries. 



Most of the following issues will vary accordingly. 
OF AC Regulations 



The U.S. Treasury Department's Office of Foreign Assets 
Control (OF AC) administers economic sanctions and 
embargo programs that require that assets and transactions 
involving the interests of target countries, target country 
nationals, and other specifically identified companies and 
individuals ("blocked parties") be frozen. All of the 
programs administered by OF AC involve declarations of 
national emergency by the President of the United States. 

Like other payment mechanisms, the ACH Network is 
subject to compliance with OF AC regulations. All U.S. 
citizens and permanent resident aliens, companies located 
in the U.S., overseas branches of U.S. companies, and, in 
some cases, overseas subsidiaries of U.S. companies come 
under OF AC jurisdiction. In terms of the ACH Network, 
this means that all U.S. ACH participants, including 
Originators, ODFIs, RDFIs, and Receivers need to be 
aware that they may be held accountable for violations of 
OFAC sanctions and must understand their compliance 
obligations. 

Detailed information relating to OFAC Regulations and 
their impact on Originators can be found within Section 
IV, Special Topics, of these Guidelines. 
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Rules Enforcement 

Originator VODFI Agreements 

Originators should be aware that each Participating DFI 
is subject to the rules enforcement requirements (i.e., the 
National System of Fines) as prescribed by the NACHA 
Operating Rules, Originators, under the terms of their 
Originator/ODFI agreements, may be held liable and 
accountable for certain procedures relating to the 
origination of ACH entries for which the Originator is 
responsible. Such liabilities may include, but are not 
limited to, the amount of any Fines assessed against the 
ODFI for a rules infraction caused by the Originator. 
Originators should ensure that they are aware of the terms 
of their agreements with their ODFIs and that they are in 
compliance with their obligations, as Originators, under 
the NACHA Operating Rules. Such compliance will help 
to reduce the possibility that any fines imposed on the 
ODFI, as a result of an ACH rules violation by the 
Originator, will be passed back to the Originator. 

Rules Enforcement Process 

The National System of Fines included in the NACHA 
Operating Rules is intended to maintain the quality of 
ACH services and to help ensure compliance by 
Participating DFIs with the requirements of the NACHA 
Operating Rules. A party to an ACH transaction may 
utilize the rules enforcement process to address any 
violation of the provisions of the NACHA Operating 
Rules. For complete information on the requirements 
governing ACH rules enforcement and the submission of 
a Report of Possible ACH Rules Violation, see the Rules 
Enforcement Chapter in Section IV of these Guidelines. 

Testing Procedure 

ODFIs should test ACH files from Originators to ensure 
that they are either in the proper NACHA format or in the 
alternative format that has been agreed upon. The level of 
testing is determined by the complexity of the application. 

The more complex the payment application, the greater 
the requirement for testing. For example, the Originator 
that is transmitting corporate transactions that include 
multiple addenda records will need to establish a level of 
testing with the ODFI that reflects the agreed upon 
parameters of the services that are to be provided by the 
ODFI. 

ODFIs should take appropriate measures to ensure that 
test data is not inadvertently entered into the live 
production system or that live files are not held in test 
mode. 

Invalid Characters 

The Originator needs to ensure that no invalid characters 
are included in ACH files. A description of those 



characters that are valid for ACH transactions can be 
found in the ACH Operator Chapter of Section II of these 
Guidelines. Use of characters falling outside of these 
parameters (including use of invalid characters within 
addenda records) will cause the batch in which the invalid 
character(s) resides to be rejected by the ACH Operator. 

Input Schedules/Availability of Funds 



An Originator must adhere to the schedules established by 
the ODFI for input of ACH files. These schedules are set 
so that the ODFI can deliver files to the ACH Operator for 
timely distribution and settlement. The Originator should 
be aware of any modification of the schedule for instances 
where the expected settlement date falls on a weekend or 
holiday. Warehousing of ACH entries by the ODFI prior 
to delivery to the ACH Operator is sometimes an option 
for Originators that wish to prepare files early. 

Adherence to input schedules will ensure compliance with 
certain rules and regulations. For example, when credits 
are originated, the NA CHA Operating Rules require that 
the RDFI make funds available for withdrawal or cash 
withdrawal on the Settlement Date. Funds must be made 
available for withdrawal or cash withdrawal at the 
opening of business on settlement date for PPD credit 
entries that are made available to an RDFI by its ACH 
Operator by 5:00 p.m. (RDFI's local time) on the banking 
day prior to the settlement date. ACH Operators offer a 
variety of input schedules mat support availability of files 
to RDFIs by a certain time each day. Every Originator 
must determine with its ODFI which input schedule to 
utilize that will ensure that the RDFIs can receive files and 
make funds available, particularly for sensitive entries 
such as direct deposit of payroll, by the opening of 
business on Settlement Date. Regulation E obligates the 
RDFI to post certain transactions to consumer accounts as 
of the payment date and requires employees' statements to 
reflect, among other things, that posting date. 

Settlement 

Effective Entry Date/Settlement Date 




The Effective Entry Date in the Company Batch Header 
Record is specified by the Originator as the date on which 
settlement for entries in that batch is expected to occur. 
The Settlement Date is inserted in the Company/Batch 
Header Record by the Receiving ACH Operator; it 
represents the Julian date on which settlement is 
scheduled to occur for the transactions contained in that 
batch. The Receiving ACH Operator determines the 
Settlement Date based on the Effective Entry Date and the 
current ACH processing date. 

Stale-Dated Entries 

Although the ACH Operator will accept stale-dated 
entries, it is not recommended that Originators insert a 
stale date in the Effective Entry Date field. When a stale 
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date is used, the actual Settlement Date will not be the 
same as the Effective Entry Date, but instead will be the 
next available business day (at least one day after the 
Effective Entry Date). This occurs when the batch was 
delivered to the ACH Operator with an Effective Entry 
Date that is the same or earlier than the date on which the 
ACH Operator processes the file. For example, a batch 
carrying an Effective Entry Date of March 1 5, 20xx would 
settle on the next available business day if March 15 were 
to fall on a Saturday, Sunday, or holiday. Use of a stale 
date can cause confusion at the RDFI because the 
Effective Entry Date and the Settlement Date would not 
be the same. Also, return entries carry the Effective Entry 
Date, not the Settlement Date of the original entry. 

Warehousing 

The Originator and ODFI must ensure that ACH entries 
are not delivered to the ACH Operator too early. ACH 
credit transactions can be submitted to the ACH Operator 
one or two business days prior to the Effective Entry Date. 
ACH debit transactions can be submitted to the ACH 
Operator one business day prior to the Effective Entry 
Date. For example, ACH credits with an Effective Entry 
Date of March 15, 20xx could be submitted to the ACH 
Operator for processing on March 14 or March 13, 20xx. 
If submitted on March 12 or earlier, the batch would be 
rejected. Similarly, ACH debits carrying an Effective 
Entry Date of March 1 5 , 20xx cannot be submitted to the 
ACH Operator prior to March 14, 20xx. The Originator 
and ODFI must determine if ACH entries should be held 
(warehoused) by the ODFI until the appropriate date on 
which they can be delivered to the ACH Operator. (It is 
assumed in the above examples that all dates are business 
days.) 



Returns, Reinitiation of Entries, Notifications of Change, 
Rejected Files 



The Originator and ODFI must determine how the 
Originator wants to receive information on returned 
entries and notifications of change. The ODFI must also 
establish procedures for notifying the Originator if a file 
or batch has been rejected, particularly in the case where 
it might be necessary for the Originator to recreate the file 
or batch. 

The NA CHA Operating Rules preclude an Originator from 
reinitiating a returned ACH entry unless (1) the entry has 
been returned for insufficient or uncollected funds; (2) the 
entry has been returned for stopped payment and 
reinitiation has been authorized by the Receiver, or (3) the 
ODFI has taken corrective action to remedy the reason for 
the return. The NACHA Operating Rules impose a limit 
on the number of times that an entry returned for 
insufficient or uncollected funds may be reinitiated by an 
Originator or its ODFI and allow such entries to be 
reinitiated no more than two times following the return of 
the original entry. This limit is effective for all Standard 



Entry Class Codes except RCK, which has its own distinct 
limit on the number of presentments. 

4. RELATIONSHIP WITH RECEIVER 

The Originator will usually develop a processing 
relationship with the Receiver only when the two parties 
have entered into a trading partner agreement for the 
transfer of funds and payment-related iriformation. When 
agreeing to formatting and remittance information 
requirements with its Receiver, the Originator is 
encouraged to make the Receiver aware that it may obtain 
all payment-related information transmitted within the 
addenda records of CCD, CTX, and CIE entries, provided 
that the Receiver requests such information from its 
RDFI. For more information on payment-related data in 
the ACH system, see the chapter on Addenda Records 
within Section IV of these Guidelines. 



SECTION II 

PARTICIPANT RELATIONSHIPS 

AND RESPONSIBILITIES 



CHAPTER II 

ORIGINATING DEPOSITORY 

FINANCIAL INSTITUTIONS 



A INTRODUCTION 

The Originating Depository Financial Institution (ODFI) 
is the depository financial institution (DFI) that has made 
an arrangement with an Originator to transmit entries into 
the ACH system on behalf of the Originator or transmits 
entries into the ACH system on its own behalf (where the 
ODFI is also the Originator). All Originating DFIs must 
also agree to act as Receiving DFIs. The ODFI is 
recognized by the Routing Number in the Originating DFI 
Identification Field of the Company/Batch Header Record 
and by the first 8 digits of the Trace Number in the Entry 
Detail Record. A financial institution whose Routing 
Number appears in these fields is considered by NA CHA 
Operating Rules and by the ACH Operator to be the 
ODFI, even if the ODFI is acting on behalf of another 
financial institution. 

B. MEMBERSHIP REQUIREMENTS 

To originate entries into the ACH Network, a DFI will 
generally become, if it is not already, a member of a local 
ACH payment association. Financial institutions that are 
not members of an ACH payment association are entitled 
to originate as prescribed by the Federal Reserve. 
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C. LEGAL CONSIDERATIONS 

1; WARRANTIES AND INDEMNIFICATIONS 

An ODFI assumes responsibility for a number of 
warranties and indemnifications. The ODFI is responsible 
■fbr:\ 

•■' ; ensuring that all entries are properly authorized; 

The NACHA Operating Rules place the responsibility 
on the ODFI to ensure that the Originator has obtained 
the authorization of the Receiver for ACH entries 
transmitted to the Receiver's account. This 
responsibility is enforced by the ODFl's warranty that 
such transactions are properly authorized, which places 
liabilities on the ODFI in the event of an unauthorized 
debit entry. Although other provisions of the Rules 
enable the recovery of funds related to unauthorized 
debits by means of the ACH return process, ODFIs 
must be aware that these return procedures are in 
addition to, rather than in lieu of, the liabilities 
established under this warranty. The right of return 
provides a means to simplify and automate this 
recovery of funds for a limited period of time. 
However, ODFIs must understand that the warranty 
language within the Rules is broad and does not limit 
itself to the period of time in which an RDFI can 
recover funds through the return of entries through the 
ACH Network, In other words, the ODFl's potential 
liability under the NACHA Operating Rules for a 
breach of warranty is not limited to the return time 
frames, but is, instead, limited only by the statute of 
limitations for breach of contract claims under the 
applicable state law. The ODFl's liability for breach of 
warranty may exist for up to seven years in some states. 

ODFIs should be aware that the NACHA Operating 
Rules permit an RDFI to request a copy of the 
Originator's authorization both before and after receipt 
of an ACH entry. An ODFI must, within ten banking 
days of receipt of an RDFI 's written request, provide a 
copy of the authorization to the RDFI without charge. 

•submitting the entries into the ACH Network in a 
timely manner in order to effect the transfer of funds on 
the appropriate date; 

• terminating the origination of entries when appropriate, 
i.e., when the authorization for the entry has been 
revoked or when the origination should cease by 
operation of law. (Note: At the time of transmission of 
the entry to the ACH Operator, the ODFI warrants that 
the Originator's authorization has not been revoked, 
that the agreements required by the Rules concerning 
the entry have not been terminated, and neither the 
ODFI, any Third-Party Sender, nor the Originator has 
actual knowledge of the revocation of the Receiver' s 
authorization or of the termination of the arrangement 



between the RDFI and the Receiver concerning the 
entry.) 

• ensuring that, for all entries involving the exchange of 
banking information via an Unsecured Electronic 
Network between a Receiver and an Originator, an 
Originator and an ODFI, an ODFI and an ACH 
Operator, or an Originator or ODFI and a Third-Party 
Service Provider, the banking information is (1) 
encrypted using a commercially reasonable security 
technology that, at a minimum, is equivalent to 128-bit 
RC4 encryption technology, or (2) transmitted or 
received via a secure session using a commercially 
reasonable security technology that provides a level of 
security that, at a minimum, is equivalent to 128-bit 
RC4 encryption technology. 

•'■ using a commercially reasonable method to establish 
the identity of each Originator that uses an Unsecured 
Electronic Network to enter into a contractual 
relationship with the ODFI for the origination of 
entries. 

• meeting the proper requirements for data security and 
personal identification numbers in certain applications 
when appropriate; 

• ensuring that the entries contain the appropriate 
information; 

• ensuring that information contained within reclamation 
entries is accurate, applies to the Receiver and account 
identified in the reclamation entry, falls within the 
timing requirements governing reclamations, has been 
properly authorized by the Receiver and that the 
authorization has not been revoked, and that any 
payments subject to reclamation are made with no 
restriction on the number of parties having an interest 
in the account; 

ensuring that an agreement has been entered into with 
a Sending Point when a Sending Point is used to 
transmit ACH entries; 

> ensuring that the ODFI and any Third-Party Service 
Provider that performs a function of ACH processing 
on behalf of the ODFI with regard to entries are in 
compliance with the audit requirements set forth in 
Appendix Eight (Rule Compliance Audit 
Requirements) of the NACHA Operating Rules; 

•; ensuring that ( 1 ) the source document used for a POP 
entry is returned voided to the Receiver after use by the 
Originator, and (2) the source document has not been 
provided by the Receiver for use in any prior POP 
entry; 

• ensuring that each Originator of TEL entries has (1) 
employed commercially reasonable procedures to 
verify the identity of the Receiver, and (2) utilized 
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commercially reasonable procedures to verify that routing 
numbers are valid; and 

• compliance with NACHA Operating Rules. 

The ODFI indemnifies the RDFI, ACH Operator, and 
Association against loss when breaching any of these 
warranties. 

ODFIs should also be aware that they assume a number of 
additional warranties with respect to the origination of 
RCK entries, WEB entries, and ARC entries. For specific 
information on these additional warranties, refer to the 
chapters on Re-presented Check Entries, Internet-Initiated 
Entries, and Accounts Receivable Entries within Section 
IV of these Guidelines. 

Limitation on Warranties 

The warranty regarding proper authorization does not 
guarantee the provision of the goods or services by the 
Originator to the Receiver or vice versa. 

2. ELECTRONIC RECORDS AND ELECTRONIC 

RECORD RETENTION 

The NA CHA Operating Rules permit ACH participants to 
obtain and store ACH records electronically as an 
alternative to obtaining and retaining such documents in 
hard copy format. Specifically, the Rules allow any 
agreement, authorization, written statement under penalty 
of perjury, or other record required by the NA CHA 
Operating Rules to be in writing to be obtained and 
retained in either hard copy or electronic form. 

Electronic Signatures and Records 

Electronic records include agreements, authorizations, 
written statements under penalty of perjury, or other 
records created, generated, sent, communicated, received, 
or stored by electronic means. Electronic records may 
have a signature requirement 

Electronic signatures are electronic sounds, symbols, or 
processes attached to or logically associated with an 
agreement, authorization, written statement under penalty 
of perjury, or other record executed or adopted by a 
person with the intent to sign the record. These writing 
and signature requirements can be satisfied by compliance 
with the Global and National Commerce Act (E-Sign 
Act). ODFIs should be aware that any record that is 
signed according to the terms of an applicable state 
version of the Uniform Electronic Transaction Act is 
considered to have been signed in conformance with the 
terms of the E-Sign Act. 

To satisfy the requirements of the NACHA Operating 
Rules (and Regulation E for preauthorized debits), 
electronic signatures must "similarly authenticate" the 
electronic records. The authentication method chosen 



must evidence both the signer's identity and his assent to 
the terms of the record. For purposes of the NA CHA 
Operating Rules, ACH records may also be similarly 
authenticated using the same authentication methods 
currently prescribed for consumer debit authorizations - 
that is, the record may be similarly authenticated via the 
Internet through the use of a digital signature, PIN, 
password, shared secret, etc., or a hard copy record may 
be authenticated via the telephone by the consumer's 
speaking or key-entering a code provided on the record. 

Any other written notice or disclosure required by the 
NA CHA Operating Rules but not requiring a signature 
may also be provided in electronic form, including e-mail 
(This includes the notice for TEL. Please note that state 
and federal laws may require consumer consent before 
using electronic notices/disclosures.) 

Record Retention 



ODFIs are permitted to retain copies of ACH records in 
electronic form, provided that the electronic record (1) 
accurately reflects information contained within the 
record, and (2) is capable of being accurately reproduced 
for later reference, whether by transmission, printing, or 
other reproduction. 

ODFIs choosing to utilize electronic communications 
methods for the retention of ACH records should 
implement practices and procedures to ensure that 
electronic records of ACH documents accurately reflect 
the information contained within the document and that 
both the electronic record and a recorded record of the 
authentication can be accurately reproduced for future 
reference. 

ODFIs should be aware that other ACH participants may 
also utilize electronic methods to obtain and retain records 
of ACH documents. In such cases, ODFIs can expect to 
receive electronic versions, rather than hard copies, of 
documents that they request from other ACH participants. 

3. AGREEMENTS/RELATIONSHIP WITH 
ORIGINATOR 

The ODFI bears full responsibility for entries it originates 
(on its own behalf or on behalf of other companies). To 
that end, it is critical that the ODFI fully understand its 
responsibilities and liabilities as an ODFI under the 
NACHA Operating Rules, The ODFI is required to 
execute a written agreement with its companies that will, 
at a minimum, bind each company to the NA CHA 
Operating Rules. The ODFI/Originator agreement should 
also address the responsibilities and liabilities of the 
Originator on whose behalf the ODFI is providing ACH 
services. Alternatively, in situations in which a Third- 
Party Service Provider, in the role of a Third-Party 
Sender, acts as an intermediary between an Originator and 
an ODFI for the origination of ACH entries, and there is 
no contractual agreement between the Originator and the 
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ODFI, the NACHA Operating Rules require appropriate 
agreements (i.e., between the ODFI and Third-Party 
Sender, between the Third-Party Sender and Originator, 
and between multiple Third-Party Senders themselves) 
under which each Third-Party Sender and Originator have 
agreed to be bound to the Rules and agreed that they will 
not originate entries in violation of the laws of the United 
States. (See the chapter on Third-Party Service Providers 
within these Guidelines for additional information on 
Third-Party Senders.) For a list of specific issues that 
should appear in an agreement between the ODFI and the 
Originator and for an example of that Agreement, refer to 
the Originators chapter within Section II of these 
Guidelines. 

In an environment where an increasing number of 
unauthorized transactions or transactions arising from 
deceptive business practices are being made over the 
ACH Network, it is becoming more and more critical that 
financial institutions take proactive steps to safeguard 
their financial assets as well as their reputations. One 
fundamental step toward this goal is to ensure that ODFIs 
know their customers. To protect themselves against 
financial losSj ODFIs must ensure that their Originators 
are credit-worthy. ODFIs should also strive to ensure that 
such Originators are engaged in reputable business 
practices. 

Although ODFIs may restrict or refuse ACH services to 
some organizations directly, it is important to be aware 
that businesses engaged in questionable business practices 
may also be originating ACH payments through Third- s 
Party Service Providers that have authorization to use the 
ODFI's routing number to transmit ACH entries directly 
to the ACH Operator (i.e., direct access). In such cases, 
the ODFI is exposed to the same financial and 
reputational risk and liability but may be unaware of or 
have no contractual agreements with the companies on 
whose behalf they are originating entries. ODFIs must 
ensure that they have thoroughly evaluated the risks and 
potential liabilities of granting direct access to the ACH 
Operator before giving any customer such capabilities. 

In addition to executing an agreement with the Originator, 
the ODFI should: 

• Conduct thorough educational programs for its 
companies providing written procedures and 
documentation on how the Originator interfaces with 
theODFI. 

• Instruct its companies on the meaning of NACHA 
Operating Rules. Solid agreements and educational 
efforts can help ensure greater compliance with the 
NACHA Operating Rules. 

• Instruct its companies on the definition of unauthorized 
debits. Inform them of the authorization requirements 
for debit and credit entries. Develop procedures to 
provide copies of authorizations when requested. 



• Develop procedures for Originators to request the 
ODFI to obtain, when necessary, a copy of a written 
statement under penalty of perjury from an RDFI when 
the Originator has received a return for R05 
(Unauthorized Debit to Consumer Account Using 
Corporate SEC Code) [effective March 18, 2005]; R07 
(Authorization Revoked by Customer); Rl (Customer 
Advises Not Authorized, Notice Not Provided, 
Improper Source Document, or Amount of Entry Not 
Accurately Obtained from Source Document) ; R3 7 
(Source Document Presented for Payment); R5 1 (Item 
is Ineligible, Notice Not Provided, Signature Not 
Genuine, Item Altered, or Amount of Entry Not 
Accurately Obtained from Item); or R53 (Item and 
ACH Entry Presented for Payment). 

• Develop a certification or testing program to ascertain 
the company's processing preparedness. 

• Develop comprehensive risk analysis procedures for 
new and ongoing company relationships. Develop 
procedures and time frames to cease processing in the 
event of origination activity that exposes the ODFI to 
undue risk. 

. • . ■ Develop policies and procedures to establish, review, 
and monitor exposure limits for each of its corporate 
Originators. 

. V ■ Instruct its corporate Originators on the definition of 
exposure ; explain its policies and procedures relating to 
limiting exposure and managing risk in the ACH. 

• Include language in the agreement with its corporate 
Originator relating to the establishment and monitoring 
of exposure limits; establish procedures between the 
ODFI and Originator for reviewing exposure limits on 
a periodic basis. 

• Provide marketing support to companies. 

ODFIs are encouraged to interface with their Originators 
via a secured telecommunications link for all ACH-related 
activity. This includes the origination and/or receipt of all 
current ACH transactions, related reports, returns, NOCs, 
and any future related applications. 

OF AC Regulations 

The U.S. Treasury Department 's Office of Foreign Assets 
Control (OF AC) administers economic sanctions and 
embargo programs that require that assets and transactions 
involving interests of target countries, target country 
nationals^ and other specifically identified companies and 
individuals be frozen. For purposes of OF AC 
compliance, these entities are called "blocked parties" and 
OF AC maintains and regularly updates a master list of 
"Specially Designated Nationals and Blocked Persons" 
("SDN List") identifying known blocked persons. All of 
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the programs involve declarations of national emergency 
by the President of the United States. 

Like other payment mechanisms, the ACH Network is 
subject to the requirement to comply with OF AC 
regulations. All U.S. citizens and permanent resident 
aliens, companies located in the U.S., overseas branches 
of U.S. companies, and, in some cases, overseas 
subsidiaries of U.S. companies fall under OF AC 
jurisdiction. In terms of the ACH Network, this means 
that all U.S. ACH participants, including Originators, 
ODFIs, RDFIs, and Receivers need to be aware that they 
may be held accountable for sanctions violations and must 
understand their compliance obligations. 

Detailed information relating to OF AC Regulations and 
their impact on Originators can be found within Section 
IV, Special Topics, of these Guidelines. 

ODFI Exposure Limits 

ODFIs are required by the NACHA Operating Rules to 
establish exposure limits for each Originator or Third- 
Party Sender transmitting or sending entries to the ODFI 
on behalf of an Originator or another Third-Party Sender. 
The ODFI must ensure that it has implemented procedures 
to review exposure limits for Originators or Third-Party 
Senders periodically and to monitor entries initiated by 
those Originators or Third-Party Senders relative to their 
exposure limits across multiple settlement dates. ODFIs 
are also required to implement procedures to monitor the 
payments system risk associated with CBR and PBR 
entries sent or transmitted by those Originators or Third- 
Party Senders. With respect to WEB entries sent or 
transmitted to the ODFI by an Originator or a Third-Party 
Sender, the ODFI warrants that it has (1) established 
procedures to monitor, on an on-going basis, the credit- 
worthiness of the Originator or Third-Party Sender; (2) 
established an exposure limit for WEB origination for the 
Originator or Third-Party Sender; (3) implemented 
procedures to review that Originator's or Third-Party 
Sender' s exposure limit for WEB entries on a periodic 
basis; and (4) implemented procedures to monitor WEB 
entries sent or transmitted by the Originator or Third- 
Party Sender, relative to its exposure limit, across multiple 
settlement dates. 

ODFIs should ensure that exposure limits are assigned 
and monitored for Originators or Third-Party Service 
Providers that act as Sending Points on behalf of the 
ODFI and transmit entries directly to the ACH Operator 
(commonly referred to as direct access). It is appropriate 
to include language covering the establishment and 
monitoring of exposure limits in the agreement between 
the Originator and the Third-Party Service Provider. 

ODFIs should understand that establishing a limit on 
origination is not sufficient The ODFI should ensure that 
it can actively measure exposure limits when processing 
ACH credit and debit entries on behalf of its customers. 



The limit should reflect ACH processing activity and 
should be monitored as a part of daily operations. The 
ODFI should ensure that it has established procedures for 
acting upon files that exceed exposure limits and for 
handling exception situations. The ODFI should be sure 
to establish procedures for collecting and monitoring 
exposure limit information that do not impede normal file 
processing. (For a comprehensive review of ACH risk 
and control issues, refer to the ACH Risk Management 
Handbook.) 

Rules Enforcement 

Originator! ODFI Agreements 

ODFIs must be aware that, in order to help to ensure 
compliance by ACH participants with the rules governing 
the ACH Network, each Participating DFI is subject to the 
rules enforcement requirements as prescribed by the 
NA CHA Operating Rules. ODFIs are liable and 
accountable for any violations of the provisions of the 
NACHA Operating Rules by either the ODFI or the 
Originator. ODFIs must be aware that fines can be 
imposed against the ODFI for violations of the NACHA 
Operating Rules . ODFIs should be aware that 
Originators, under the terms of their Originator/ODFI 
agreements, may be held liable and accountable for 
certain procedures relating to the origination of ACH 
entries for which the Originator is responsible. ODFIs 
may wish to review their agreements with their 
Originators to be sure that issues relating to ACH rule 
violations and liabilities are properly addressed. 

Rules Enforcement Process 

The National System of Fines included in the NACHA 
Operating Rules is intended to maintain the quality of 
ACH services and to help ensure compliance by 
Participating DFIs with the requirements of the NA CHA 
Operating Rules, A party to an ACH transaction may 
utilize the rules enforcement process to address any 
violation of the provisions of the NACHA Operating 
Rules. For complete information on the requirements 
governing the National System of Fines and the 
submission of a Report of Possible ACH Rules Violation, 
see the Rules Enforcement Chapter in Section IV of these 
Guidelines. 

4. AGREEMENTS/RELATIONSHIP WITH 
THIRD-PARTY SERVICE PROVIDER 

In some cases, the ODFI may choose to utilize the 
services of a Third-Party Service Provider. When such a 
Third-Party Service Provider acts as a Sending Point for 
the ODFI, the ODFI warrants that it has entered into an 
agreement between itself and the Third-Party Service 
Provider. 

To accommodate the business practice in which a Third- 
Party Service Provider, in the role of a Third-Party 
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Sender, acts as an intermediary between an Originator and 
an ODFI for the origination of ACH entries, and there is 
no contractual agreement between the Originator and the 
ODFI, the NACH A Operating Rules require appropriate 
agreements (i.e., between the ODFI and Third-Party 
Sender, and between the Third-Party Sender and the 
Originator) under which each Third-Party Sender and 
Originator have agreed to be bound to the Rules and 
agreed that they will not originate entries in violation of 
the laws of the United States. 

For additional information on Third-Party Service 
Providers and Third-Party Senders, refer to the Third- 
Party Service Provider chapter within Section IV of these 
Guidelines. 

D. ACKNOWLEDGMENT ENTRIES 

ODFIs may choose to provide ACH acknowledgment 
services to their corporate Originators, with which 
Originators may request an acknowledgment from the 
RDFI mat a corporate credit entry (CCD, CTX entry) has 
been received by the RDFI. 

ACH acknowledgment entries are optional, non-dollar 
transactions that may be used by anRDFI to acknowledge 
that a corporate ACH credit entry has been received and 
mat the RDFI will attempt to post the payment to the 
Receiver's account. ODFIs choosing to provide ACH 
acknowledgment services to their corporate Originators 
will need to ensure that their ACH origination software 
has been modified to accommodate the transmission of a 
request for an acknowledgment entry within the forward 
CCD or CTX entry (i.e., placement of "AK" within the 
Discretionary Data field of the forward CCD or CTX 
entry) . ODFIs providing acknowledgment services will 
also be required to develop the capabilities to identify and 
process acknowledgment entries (and refused 
acknowledgment entries when appropriate) on behalf of 
their customers. For additional information on how to 
utilize the ACH acknowledgment process, refer to the 
chapter entitled Acknowledgment Entries within Section 
III of these Guidelines. 

E. CROSS-BORDER ENTRIES 

The CBR and PBR Standard Entry Class Codes must be 
used by Originators when transmitting cross-border ACH 
credit and debit entries. The CBR Standard Entry Class 
Code is used for the transmission of corporate cross- 
border entries, and the PBR Standard Entry Class Code is 
used for the transmission of consumer cross-border 
transactions. These Standard Entry Class Codes allow 
cross-border transactions to be readily identified by 
financial institutions so that they may, if desired, apply 
special handling requirements for cross-border payments. 
These formats enable ACH participants to transmit and 
receive detailed information that is unique to cross-border 
payments. 



The cross-border formats utilize a unique Company/Batch 
Header Record to convey information relating to foreign 
exchange, origination and destination currencies, and 
destination country. Each CBR and PBR Entry Detail 
Records is accompanied by one mandatory addenda 
record, within which information relating to the foreign 
receiving DFI, foreign payment amount, foreign trace 
number, and foreign receiver's account number is 
conveyed. 

For CBR and PBR return entries, unique Company/Batch 
Header Records and Addenda Records accommodate the 
return of cross-border-specific information. The Entry 
Detail Record used for cross-border returns is the same 
format used for all other returns but has been expanded to 
accommodate cross-border information. 

A unique Company/Batch Header Record accommodates 
cross-border dishonored returns, contested dishonored 
returns, NOCs, and refused NOCs. The existing Entry 
Detail Records and Addenda Records for dishonored 
returns, contested dishonored returns, NOCs, and refused 
NOCs have been expanded to accommodate cross-border 
payments. 

For additional information relating to Cross-Border 
Payments, refer to Section IV of these Guidelines. For 
specific information on formatting requirements and 
technical specifications associated with the CBR and PBR 
Standard Entry Class Codes, refer to the NACHA 
Operating Rules : 




■F. POINT-OF-PURCHASE ENTRIES ' 

A Point-of-Purchase (POP) entry is a Single-Entry ACH 
debit entry, initiated by an Originator (i.e., a merchant, 
biller, etc.) to a consumer's account for the in-person 
payment for goods or services. These one-time debit 
entries are initiated by the Originator based on a written 
authorization and account information drawn from a 
source document (check) obtained from the consumer at 
the point-of-purchase. The source document, which is 
voided by the merchant and returned to the consumer at 
the point-of-purchase, is used to obtain the consumer's 
routing number, account number, and check serial number 
that will be used to generate the debit entry to the 
consumer's account. For detailed information on 
originating POP entries, refer to the Point of Purchase 
Entry chapter within SectionlV of these Guidelines. 

G. RE-PRESENTED CHECK ENTRIES 

A Re-presented Check (RCK) entry is a Single-Entry 
ACH debit entry used by Originators (merchants, billers, 
etc.) as an alternative method of collecting checks that 
have been returned because of insufficient or uncollected 
funds. This method of collection via the ACH Network, 
when compared to the check collection process, provides 
Originators with the potential for improvements to 
processing efficiency (such as control over timing of the 
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initiation of the debit entries) and decreased costs. For 
detailed information on RCK entries, see Section IV, of 
these Guidelines. 

H. ACCOUNTS RECEIVABLE ENTRIES 

An Accounts Receivable (ARC) Entry is a Single-Entry 
ACH debit used by Originators to convert a consumer 
check that is received via the U.S. mail or at a dropbox 
location for the payment of goods or services. For the 
ARC application, the consumer's check is viewed solely 
as source document, from which the consumer's routing 
number, account number, check serial number, and dollar 
amount for the transaction are captured for use in the 
ACH debit entry. For detailed information on Accounts 
Receivable Entries, see the Accounts Receivable Entries 
chapter within Section IV of these Guidelines. 

I. INTERNET-INITIATED ENTRIES 

Originators initiating debit entries (both recurring and 
Single Entry) to a consumer account pursuant to an 
authorization that is obtained from the Receiver via the 
Internet are required to utilize the WEB (Internet-Initiated 
Entry) Standard Entry Class Code. This SEC Code 
addresses unique risk issues that are inherent to the 
Internet payment environment through requirements for 
added security procedures and obligations. For detailed 
information on originating WEB entries, see Section IV, 
of these Guidelines. 

J. TELEPHONE-INITIATED ENTRIES 

Originators of Single-Entry debits to consumer accounts 
may obtain an oral authorization for such an entry from 
the consumer via the telephone. These Single-Entry 
debits, which must utilize the TEL Standard Entry Class 
Code, may only be originated when either ( 1 ) there is an 
existing relationship between the Originator and the 
Receiver, or (2) there is no existing relationship between 
the Originator and the Receiver, but the Receiver has 
initiated the telephone call For detailed information on 
originating TEL entries, refer to the Telephone-Initiated 
Entries chapter within Section IV of these Guidelines. 

K. PROCESSING REQUIREMENTS 

The ODFI must have the ability, either within its own 
processing environment or through a processing agent, to 
initiate ACH files to the ACH Operator in the proper 
format All ODFIs designate one or more Sending Points 
that will deliver files to the ACH Operator. For 
information on using Third-Party Service Providers as 
Sending Points, see Section IV of these Guidelines. 

. i. transaction codes :; ; ;.;-;. 

The NACHA Operating Rules permit Originators to 
transmit ACH credit and debit entries to demand accounts 
(i.e., checking, NOW, and sharedraft accounts) and 



savings accounts at an RDFI. The NACHA Operating 
Rules also permit Originators to transmit both credit and 
debit entries to financial institutions' general ledger 
accounts and to transmit credit entries only (with the 
exception of reversals to correct erroneous credit entries) 
to loan accounts. 

."■■■ Financial Institution General Ledger Accounts — Both 
ACH credit and debit entries may be transmitted to 
financial institutions' general ledger accounts. Entries 
transmitted to a financial institution's general ledger 
account are corporate transactions and must be properly 
authorized by the Receiver (in this case, the RDFI) in 
accordance with the requirements of the NA CHA 
Operating Rules. 

• Loan Accounts — Originators may transmit ACH credit 
entries to loan accounts belonging to a Receiver. 
Originators must be aware, however, that, with the 
exception of reversals to correct erroneous credits, 
debit entries to loan accounts are prohibited. The ACH 
Operators have established edits that cause any debit 
entry without the word "REVERSAL" in the Company 
Entry Description field to reject and be returned to the 

0DFL 

As loan accounts are not covered by Regulation E, 
RDFIs are not subject to periodic statement 
requirements as defined by Regulation E. Because of 
the varying statement practices of RDFIs concerning 
these types of accounts, ODFIs may not become aware 
of the unlikely possibility of fraudulent ACH debit 
reversal activity through the typical ACH return process 
or time frames. Under these circumstances, 
inappropriate ACH debit reversal activity may not be 
detected by a consumer until he receives notice that a 
loan obligation has increased or until a line of credit is 
unavailable for use by the consumer. ODFIs should 
review their risk management and monitoring 
procedures to ensure that ACH reversal activity is 
addressed. 

Source documents that are currently used to obtain the 
routing and account information fordemand and savings 
accounts (for example, a voided check or sharedraft) are 
not available for use with loan or general ledger accounts. 
For such entries, Originators must rely on other 
documentation provided by the Receiver (such as a credit 
card statement, loan account statement, or coupon book) 
to obtain loan account information. ODFIs must ensure 
that Originators provide them with information relating to 
the types of accounts to which these entries will be 
directed. 

ODFIs should be aware that the NACHA Operating Rules 
permit an RDFI to return any entry that concerns an 
account that is not a "transaction account" as defined by 
Regulation D of the Board of Governors of the Federal 
Reserve System. Because loan accounts and general 
ledger accounts do not fall within the Regulation D 
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definition of a "transaction account," an RDFI may 
exercise its right to return any payment directed to these 
accounts using Return Reason Code R20 (Non- 
Transaction Account), provided the return entry complies 
with all rules governing return entries. 

2. FILE REQUIREMENTS : 

The ODFI and/or Sending Point must make arrangements 
with the Originator to receive and process the file in 
sufficient time to meet various input schedules established 
by their ACH Operator. The medium and format of the 
file or payment information that flows from the Originator 
to the ODFI are determined by the ODFI and the 
Originator. However, when files are delivered to the 
ACH Operator, they must meet the format specifications 
ofiheNACHA Operating Rules. The ODFI should have 
the Originator maintain a backup file and/or prepare 
contingency procedures in the event a file or batch cannot 
be processed. 

3. ACH DATA SECURITY REQUIREMENTS 

Because of the nature of ACH files and the potential 
dollar value of the file, it is good practice to design 
delivery procedures for tape files and/or 
telecommunications from the Originator with careful 
attention to security to prevent entry of fraudulent or 
unauthorized files. Because of the sensitivity of data on 
the files, all ACH files should be maintained in a secure 
environment to ensure customer privacy. Use of ACH 
data for purposes other than to effect the transfer of funds 
is not endorsed by NACHA and, in some cases, may be 
illegal. 

For certain applications (CCD and CTX credits), the level 
of security that is in place between the Originator and the 
ODFI could determine liability in the case of unauthorized 
or erroneous ACH activity. The ODFI must be familiar 
with various components of a "commercially reasonable 
security procedure" as defined by the Uniform 
Commercial Code Article 4A and determine the level of 
security that is appropriate for the ACH activity it 
originates. 

For all ACH transactions that involve the exchange or 
transmission of banking information (which includes, but 
is not limited to, an entry, entry data, a routing number, an 
account number, and a PIN or other identification symbol) 
via an Unsecured Electronic Network, the NACHA 
Operating Rules impose specific data security 
requirements for those ACH transactions, regardless of 
the SEC Code contained within the entry. An Unsecured 
Electronic Network is a public or private network that is 
not located entirely within a single, contiguous, physical 
facility and any part of which that has hot implemented 
security technologies that provide a level of security that, 
at a rninimum, is equivalent to 128-bit RC4 encryption 
technology. 



Specifically, any banking information that is transmitted 
or exchanged via an Unsecured Electronic Network must 
be either (1) encrypted using a commercially reasonable 
security technology that, at a minimum, is equivalent to 
1 28-bit RC4 encryption technology, or (2) transmitted via 
a secure session that utilizes a commercially reasonable 
security technology that provides a level of security that, 
at a minimum, is equivalent to 128-bit RC4 encryption 
technology. Such encryption technology must be 
employed prior to the key-entry and through the 
transmission of any banking information exchanged/via 
an Unsecured Electronic Network, between (1) an 
Originator and a Receiver; (2) an Originator and an ODFI; 
(3) an ODFI and an ACH Operator; (4) an ACH Operator 
and an RDFI; and (5) an Originator, ODFI, RDFI, or 
ACH Operator and a Third-Party Service Provider. 

Transmissions or exchanges of banking information using 
voice or keypad inputs from a wireline or wireless 
telephone are not subject to this data security requirement 
unless the telephone is used to access the Internet. An 
application in which the Originator obtains information 
from the Receiver by another means (such as the 
telephone) and then key enters the information via the 
Internet would, for example, be subject to these data 
security requirements. However, information delivered 
via a telephone line, such as a leased line, or dialed into a 
financial institution's modempool would not be subject to 
this requirement. 

Verification of Identity of Originators 

The NACHA Operating Rules also require ODFIs to 
utilize commercially reasonable methods to establish the 
identity of each Originator that uses an Unsecured 
Electronic Network, such as the Internet, to enter into a 
contractual relationship with the ODFI for the origination 
of ACH transactions. Such a requirement helps to ensure 
that ODFIs employ measures to know the Originators with 
whom they establish relationships over Unsecured 
Electronic Networks and to verify those Originators' 
identities. 

.4. PROCESSING OUTLINE ' ; - .■.■.:■/;■.■.;:■;■:.■ .J: ;: ; ;:. ; . ■; 

Processing requirements for Sending Points and/or ODFIs 
should include, but are not limited to, the following: 



Receiving and Editing Files 
Standard editing includes validating: 




• that the file is not a duplicate of one that has previously 
been processed; 

'• the Originator information, including qualification to 
originate; 

• the field contents, such as codes and numeric 
requirements; 
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•■ that origination activity does not exceed agreed upon 
limits. 

Consolidation of ACH Files 

The ODFI consolidates the files of all of its companies for 
entry into the ACH Network: 

• A single file (i.e., a composite file containing batches 
for all Originators) meeting the requirements of the 
NA CHA Operating Rules should be created. 

■• The ODFI ensures that the file contents are valid and 
will meet the ACH Operator's editing criteria. 

• The ODFI assigns trace numbers to each record. These 
numbers must be unique within a batch since they are 
the primary means of identifying an entry. The 
uniqueness of the trace number should not depend on 
the creation date, effective entry date, or any other 
piece of information within the batch. 

On-us Entries 

An on-us entry is an entry that belongs at the ODFI, e.g., 
where the Receiver's account resides at the ODFI. The 
ODFI may strip off these entries from the Originator's 
ACH file prior to delivering the file to the ACH Operator. 
Warehousing of on-us entries may be necessary for the 
entries to be posted on the appropriate date. For example, 
when payroll credits are delivered to the ACH Operator 
on Wednesday for a Friday pay date, the ODFI should 
warehouse the on-us entries from that same payroll file 
until Friday, the same date that the other entries will be 
posted at the RDFIs. 

The degree to which this processing is automated is the 
option of the ODFI. Alternatives to in-house software 
development are available through several software 
packages offered by commercial vendors. 

5. EXCUSED DELAY 

The provisions within the NA CHA Operating Rules with 
respect to excused delay help to clarify circumstances in 
which a processing delay by a Participating DFI or ACH 
Operator would be excused. In certain circumstances, a 
delay in acting on an ACH entry may result in a loss to a 
Participating DFI. In these situations, it is necessary to 
allocate such a loss among the Participating DFIs. 

For example/if an RDFI delays the return of an ACH 
debit entry to the ODFI, and the ODFI is unable to charge 
the transaction back to the Originator because the 
Originator has become insolvent, the delay will result in 
a loss to the ODFI. When the return is due to insufficient 
funds rather than a breach of the ODFFs warranty that the 
entry is authorized, the RDFI will ultimately incur this 
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loss unless the delay is excused in accordance with the 
NACHA Operating Rules. 

DFI and ACH Operator operational outages due to the 
general failure or interruption of communication or 
computer facilities or other equipment do not constitute an 
excused delay. In other words, DFIs and ACH Operators 
should expect that computer problems will occur and 
should make contingency plans to handle such situations. 
In this regard, the NACHA Operating Rules governing 
excused delay are consistent with general guidance from 
the Federal Financial Institutions Examination Council 
(FFIEC) regarding contingency backups, which states that 
"All computer installations must make formal 
arrangements for alternative processing capability..." 

Although the NACHA Operating Rules 'governing excused 
delay require backup systems to protect DFIs and ACH 
Operators from delays caused by computer failure, the 
failure of a DFFs or ACH Operator's systems due to 
circumstances beyond their control may still constitute an 
excused delay, provided that such diligence as the 
circumstances require is exercised. 

L. RELATIONSHIP WITH ACH OPERATOR 

1. DELIVERY OF ACH FILES 

Procedures for delivery of files to the ACH Operator vary 
widely. For suggested procedures and practices, see the 
ACH Operator chapter of this section. In any event, the 
ODFI or Sending Point must adhere to local procedures 
and schedules. 



It is the responsibility of the ODFI to release entries at the 
proper time. Many ODFIs make use of the Effective 
Entry Date supplied by the Originator to control the 
release of me batch to effect the desired settlement. The 
process is generally referred to as "warehousing by the 
ODFI." 

In the event the Effective Entry Date falls on a weekend 
or holiday, the ODFI should consider: 

• Informing the Originator to advise credit recipients that 
credit will be delayed until the next available business 
day. 

.•■ '■ Releasing credit entries a day early for availability and 
settlement to occur before the weekend or holiday. 
(The Effective Entry Date may need to be changed in 
this case.) 

The Receiving ACH Operator will insert a Julian date, the 
date on which settlement is scheduled to occur, in the 
Company/Batch Header Record. This field is used by 
RDFIs to perform account reconciliation between the 
RDFI and the ACH Operator or between the RDFI and its 
correspondent. RDFIs post ACH entries to Receivers' 
accounts as of the Settlement Date. 
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2. FILE ACKNOWLEDGMENTS 

ACH Operators make file acknowledgments available to 
Sending Points as soon as possible after the completion of 
AGH Operator edits on an incoming file. It is the 
responsibility of the Sending Point to obtain 
acknowledgments from the AGH Operator and perform 
the necessary processing to determine the status of a 
company's file (processed or unprocessed) and 
communicate this information to the Originator. If a 
Sending Point is not the ODFI, it should be agreed upon 
by the parties whether notification of acknowledgments 
should be provided by the Sending Point to the ODFI for 
notification to the Originator, or directly from the Sending 
Point to the Originator. Upon receipt of the 
acknowledgment from the AGH Operator, the information 
should be made available to the Originator as soon as 
possible. 



The file acknowledgment will also include information on 
batches that have rejected. A Sending Point may choose 
only to report rejected batches/files to the ODFI or 
Originator. However, a Sending Point should retain all 
acknowledgment information within its system or storage 
facilities for a period of six years. 



It is recommended that the Sending Point report processed 
files to Originators to promote a proactive versus reactive 
environment. Following is the information that an AGH 
Operator will make available to a Sending Point. The 
Sending Point should communicate this information to the 
ODFI or Originator: 

File level acknowledgment information: 

• Immediate Origin 

• Immediate Origin Name (if available) 
.•'■■ File Creation Date 

• File Creation Time (if available) 
•File ID Modifier 

• File Entry/Addenda Count 

• Total Credit Entry Dollar Amount in File 

• Total Debit Entry Dollar Amount in File 
V File Batch Count 

The acknowledgment also contains the date and time the 
file was processed by the ACH Operator and, if the file 
was rej ected by the ACH Operator, the reason for the 
rejection. 

Batch level rejection information: 

'• Originating DFI Identification 

• Originating DFI Name (if available) 

• Company Name 

• Batch Number 

*■; Company Identification 

• Effective Entry Date 

8 Batch Entry/Addenda Count 

• Total Debit Dollar Amount 



• Total Credit Dollar Amount 

* Reason for Batch Rejection 

Batch level acknowledgment information may not be 
available from an ACH Operator if an entire file is 
processed without error or if the entire file is rejected. 
Batch level reject information is available for a specific 
batch(es) that has rejected. 



A Sending Point (and ODFI) can determine the method 
that will be used for reporting acknowledgments to the 
ODFI and/or Originator. 

3. RETURNS/REINITIATED ENTRIES/NOCS/ 
REJECTED FILES 

The ODFI must be aware that all returns and notifications 
of change will be delivered by the ACH Operator to the 
ODFI's Receiving Point, regardless of what the Sending 
Point of the file was. The ODFI's receiving software must 
be able to identify these entries for possible action or for 
distribution back to the Originator. 

The NA CHA Operating Rules preclude an Originator from 
reinitiating a returned AGH entry unless (1) the entry has 
been returned for insufficient or uncollected funds; (2) the 
entry has been returned for stopped payment and 
reinitiation has been authorized by the Receiver, or (3) the 
ODFI has taken corrective action to remedy the reason for 
the return. The NACHA Operating Rules impose a limit 
on the number of times that an entry returned for 
insufficient or uncollected funds may be reinitiated by an 
Originator or its ODFI> allowing such entries to be 
reinitiated no more than two times following the return of 
the original entry. This limit applies to all Standard Entry 
Glass Codes except for RCK, which has its own distinct 
limit on the number of presentments. 

For more information on handling returns, reinitiation of 
entries, notifications of change, and rejected files, refer to 
the chapter on ACH Operators within Section II and the 
chapters on Notifications of Change and Returns, 
Dishonored Returns, Contested Dishonored Returns 
within Section III of these Guidelines. 

Unauthorized Corporate Debits 

An unauthorized debit entry to a corporate/business 
account must be returned by the RDFI, using Return 
Reason Code R29 (Corporate Customer Advises Not 
Authorized), so that it is received by the RDFFs ACH 
Operator by its deposit deadline for the return entry to be 
made available to the ODFI no later than the opening of 
business on the second banking day following the 
Settlement Date of the original entry. 

If that time frame has expired, the RDFI may (but is not 
required to) contact the ODFI and ask for permission to 
return the entry beyond the deadline based on the 
Receiver's claim that the debit is unauthorized. Although 
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the NA CHA Operating Rules do not require that the ODFI 
act upon such a request, the ODFI should carefully 
consider its warranty that all transactions are properly 
authorized. It is recommended that the ODFI establish 
procedures to determine the validity of the claim. Failure 
to agree to accept such a return does not relieve the ODFI 
of its warranty and subsequent liability if the RDFI or 
Receiver chooses to pursue the claim outside of the ACH 
return process. 

If the ODFI agrees to accept the return, the RDFI would 
initiate the return entry with the Return Reason Code R3 1 
- Permissible Return Entry. The RDFI should not use this 
code unless it has received permission from the ODFI to 
return the entry. Use of this code without the permission 
of the ODFI could result in a dishonor of the return entry. 

For additional information, refer to the chapter on 
Returns, Dishonored Returns, and Contested Dishonored 
Returns within Section III of these Guidelines. 

Unauthorized/Improper Consumer Debits 

If an ODFI receives a return for R05 (effective March 1 8, 
2005), R07, RIO, R37, R51, or R53, it should be aware 
that the RDFI is warranting that it has obtained a written 
statement under penalty of perjury from the Receiver in 
which the Receiver states that the debit entry was not 
authorized, that the entry was improper, or that the 
authorization was previously revoked in the manner 
specified on the original authorization. Should the ODFI's 
customer (the Originator) need to obtain a copy of the 
written statement under penalty of perjury, a written 
request from the ODFI for the copy must be received by 
the RDFI within one year of the date on which the 
adjustment entry was initiated by the RDFI. The RDFI is 
required to provide a copy of the written statement under 
penalty of perjury within sixty days of receipt of the 
ODFI's written request for the copy. ODFIs should 
establish procedures with their Originators to accept and 
process their requests for copies of such documents. (A 
sample written statement under penalty of perjury may be 
found in Section II of these Guidelines within the chapter 
on Receiving Depository Financial Institutions.) 

IVL SETTLEMENT 

Settlement with the ODFI for entries originated is 
determined by the procedures established by the ODFI's 
ACH Operator (see ACH Operator Chapter in Section II). 
If the scheduled settlement date of a credit entry is not a 
banking day for the DFI, but the applicable Federal 
Reserve office is open on that date, settlement shall occur 
on the scheduled date. Specific procedures and timing of 
settlement between the ODFI and the Originator are solely 
at the discretion of the ODFI and the Originator. 



Non-Settlement 

It is possible that an RDFI to which entries have been 
directed will be unable to meet its settlement obligation. 
In this scenario, the ACH Operator will return the affected 
entries to the ODFI using a specific Return Reason Code. 
For additional information on the return of these entries, 
refer to the chapter on Returns, Dishonored Returns, 
Contested Dishonored Returns in Section III of these 
Guidelines. 

The ODFI should also take steps to incorporate risk 
management procedures to ensure that ACH origination 
activity does not contribute to its own inability to meet the 
settlement requirements of its ACH Operators. For 
additional information, see Section II under the chapter on 
ACH Operators within these Guidelines. 

N. AUDIT REQUIREMENTS 

All ODFIs and any Third-Party Service Providers 
performing a function of ACH processing on behalf of 
those ODFIs are required to perform an annual audit to 
determine compliance with certain rules regarding the 
origination of ACH entries. Under the NA CHA Operating 
Rules, each ODFI warrants the completion of the rules 
compliance audit by the ODFI and any third party that 
processes on its behalf. Both ODFIs and their Third-Party 
Service Providers must retain documentation supporting 
the completion of an audit of ACH rules compliance for 
a period of six years from the date of the audit and must 
provide such documentation to the National Association 
upon request. ODFIs should be aware that such 
documentation will not be asked for in an arbitrary or 
capricious manner; rather, proof of an audit will be 
requested only when deemed reasonably necessary by the 
National Association. Acceptable documentation may 
include, but is not limited to, a letter from an internal, 
outside or independent auditor indicating satisfactory 
performance of all audits. 

The NACHA Operating Rules require ODFIs and any 
Third-Party Service Providers performing a function of 
ACH processing on behalf of those ODFIs to perform an 
annual audit that addresses the specific requirements listed 
below. When conducting the annual audit, ODFIs must 
understand that these audit provisions do not prescribe a 
specific methodology to be used for the completion of an 
audit but identify key rule provisions that should be 
examined during the audit process. ODFIs should rely on 
the guidance of their auditors with respect to the specific 
auditing practices and procedures that must be followed. 

.•■' Verify that records of entries, including return and 
adjustment entries, transmitted from or to an ACH 
Operator are retained for six years from the date the 
entry was transmitted. Also verify that a printout or 
reproduction of the information relating to the entry can 
be provided to the Participating DFI's customer or any 
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other Participating DFI or ACH Operator that 
originated, transmitted, or received the entry. 

Verify, when electronic records are used, that such 
records (1) accurately reflect the information contained 
within the record, and (2) are capable of being 
accurately reproduced for later reference, whether by 
transmission, printing, or otherwise. 

Ensure that agreements have been made with all 
Originators (corporate customers) or Third-Party 
Senders that bind the Originator or Third-Party Sender 
to the NA CHA Operating Rules, and that, within such 
agreements, the Originator or Third-Party Sender 
acknowledges that entries may not be initiated that 
violate the laws of the United States. With respect to 
CBR and PBR entries, ODFIs must verify that 
agreements contain all necessary provisions. 

Verify that, if applicable, agreements have been made 
with all Sending Points originating transactions on 
behalf of the ODFI. 



Review internal procedures and customer agreements 
to ensure compliance with UCC Article 4 A. (Note: 
This review of compliance with UCC 4A is with respect 
to ACH transactions only.) 

Review internal procedures to determine that exposure 
limits are established for each corporate Originator or 
Third-Party Sender, that these procedures provide for 
the exposure limits to be reviewed periodically, and for 
entries initiated by these Originators or Third-Party 
Senders to be monitored relative to the exposure limits 
across multiple settlement dates. 

Ensure that the ODFI has implemented procedures to 
monitor the payments system risk associated with the 
initiation of CBR and PBR entries by each Originator 
or Third-Party Sender. 

For WEB entries, also review internal procedures to 
ensure that the ODFI has established procedures to 
monitor the credit worthiness of each Originator or 
Third-Party Sender on an on-going basis. Also review 
internal procedures to ensure that the ODFI has 
established an exposure limit for each Originator or 
Third-Party Sender, has implemented procedures to 
review that exposure limit periodically, and 
implemented procedures to monitor entries initiated by 
that Originator or Third-Party Sender relative to its 
exposure limit across multiple settlement dates. 

Review internal procedures to ensure that information 
relating to NOCs and Corrected NOCs is provided to 
each Originator or Third-Party Sender within two 
banking days of the settlement date of the NOC or 
Corrected NOC in accordance with Appendix Six. 



Review internal procedures to ensure that, when agreed 
to by the ODFI, Permissible Return Entries are 
accepted in accordance with Article Eight, section 8.3 
(ODFI Agrees to Accept CCD or CTX Return). 

Ensure that Originators and Third-Party Senders are 
kept informed of and are in compliance with their 
obligations on a continuing basis, including 
requirements that: 

- the Originator obtain the Receiver's authorization for 
entries, and that copies of such authorizations are 
provided to the Receiver in accordance with the 
requirements of these rules. 

- if Originators choose to initiate prenotification 
entries, they do so as required by the NACHA 
Operating Rules. 

■— entries returned as "R07 - Authorization Revoked by 
Customer," "R08 - Payment Stopped," or "RIO - 
Customer Advises Not Authorized, Notice Not 
Provided, Improper Source Document, or Amount of 
Entry Not Accurately Obtained from Source 
Document" are not reinitiated unless subsequent 
authorization of their customers has been obtained. 

- entries returned for R01 (Insufficient Funds) or R09 
(Uncollected Funds) are not reinitiated in excess of 
the limits prescribed by these rules. 

- upon receipt of returns relating to prenotifications 
indicating that the RDFI cannot accept such entries, 
such entries are not initiated. 

■- upon receipt of Notifications of Change, requested 
changes are made within six banking days of receipt 
of the NOC information or prior to initiating the next 
entry to the Receiver's account, whichever is later. 

- reversing files and reversing entries are transmitted 
to the Receiving ACH Operator in such time as to be 
transmitted or made available to the RDFI within 
five banking days following the settlement date of 
the erroneous entry or file. 

- Originators initiating POP entries provide the 
Receiver with a receipt that contains information 
relating to the POP entry, as required by these rules. 

-.' Originators initiating POP entries void and return to 
the Receiver the source document used for the ACH 
transaction. 

- Originators of WEB entries have employed a 
commercially reasonable fraudulent transaction 
detection system to screen such entries. 
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Originators of WEB entries have used commercially 
reasonable procedures to verify that routing numbers 
are valid. 

Originators of WEB entries have employed 
commercially reasonable methods of authentication 
to verify the identity of each Receiver. 

Originators of WEB entries have established a secure 
Internet session with each Receiver utilizing a 
commercially reasonable security technology 
providing a level of security that, at a minimum, is 
equivalent to 128-bit RC4 encryption technology 
prior to the Receiver's key entry of any banking 
information, including, but not limited to, the 
Receiver's routing number, account number, and 
personal identification number (PIN) or other 
identification symbol. 

Originators of WEB entries conduct annual audits to 
ensure that the financial information they obtain from 
Receivers is protected by security practices and 
procedures that include, at a minimum, adequate 
levels of ( 1 ) physical security to protect against theft, 
tampering, or damage; (2) personnel and access 
controls to protect against unauthorized access and 
use; and (3) network security to ensure secure 
capture, storage, and distribution. 

Originators initiating entries for which any banking 
information, including, but not, limited to, an Entry, 
Entry Data, a routing number, an account number, 
and a PIN or other identification symbol, is 
transmitted or exchanged between a Receiver and an 
Originator, an Originator and an ODFI, or an 
Originator and a Third-Party Service Provider, via an 
Unsecured Electronic Network, have, prior to the key 
entry and through transmission of any banking 
information, (1) encrypted the banking information 
using a commercially reasonable security technology 
that, at a minimum, is equivalent to 128-bit RC4 
encryption technology, or (2) transmitted or received 
the banking information via a secure session using a 
commercially reasonable security technology that 
provides a level of security that, at a minimum, is 
equivalent to 128-bit RC4 encryption technology. 

Transmissions or exchanges of banking information 
using voice or keypad inputs from a wireline or 
wireless telephone are not subject to this data 
security requirement unless the telephone is used to 
access the Internet. 

-Originators of TEL entries have (1) employed 
commercially reasonable procedures to verify the 
identity of the Receiver, and (2) utilized 
commercially reasonable procedures to verify that 
routing numbers are valid. 



- For ARC and RCK entries, the Originator has 
provided clear and conspicuous notice of the check 
conversion/truncation policy. 

For additional information on audits for ODFIs, see the 
chapter on Audit Controls and Compliance in Section IV 
of these Guidelines. 

Q. DESTROYED CHECK ENTRIES 

A financial institution (collecting institution), at its option, 
may utilize the ACH in the check collection process when 
certain checks have been irretrievably lost or destroyed. 
The collecting institution (in the check collection 
mechanism) becomes the ODFI in the ACH process. Use 
of the ACH in this scenario allows the ODFI to convert 
the check information into ACH debit format utilizing the 
XCK (Destroyed Check Entries) Standard Entry Class 
Code. The ODFI accepts all liability for this application 
and sets forth specific warranties regarding the origination 
of XCK entries. 

Several advantages are realized by utilizing the ACH for 
this purpose: 

8 acceleration of the recovery process. 

• reduction in float. 

• reduction of potential losses due to delays in 
presentment. 

• reduction of potential losses due to encoding errors. 
•■'. reduced costs. 

The disadvantages to the ODFI of utilizing the ACH for 
this purpose are: 

• the extensive warranties that are set forth by the ODFI 
initiating XCK entries. 

• the likelihood that a large number of entries could be 
returned. 

Each financial institution that is faced with the scenario of 
having to collect irretrievably lost or destroyed checks 
will need to determine, on a case by case basis, whether 
the advantages and disadvantages of utilizing the ACH for 
this purpose outweigh the advantages and disadvantages 
of following standard check remake procedures. 

For specific information regarding the origination of XCK 
entries, see Section IV of these Guidelines. 
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section ii :: 

PARTICIPANT RELATIONSHIPS 
AND RESPONSIBILITIES 



CHAPTERIII 
ACH OPERATORS 

A. INTRODUCTION 



The NA CHA Operating Rules define an ACH Operator as 
either ( 1) a Federal Reserve Bank that performs all of the 
following, or (2) an entity that executes an annual 
agreement with the National Association in which the 
entity agrees to comply with or perform all of the 
following: 

- adhere to the NACHA Operating Rules (except to the 
extent inconsistent with the policies or practices of the 
Federal Reserve Banks) and other applicable laws, 
regulations, and policies; 

- execute agreements with a minimum of twenty 
independent (i.e., not owned by the same holding 
company) Participating DFIs that bind such entities to 
the ACH Operator's rules and to the NACHA Operating 
Rules (except that a Federal Reserve Bank shall not be 
required to bind a Participating DFI to any provision of 
such rules of the National Association that is not 
incorporated by the Uniform Operating Circular of the 
Federal Reserve Banks); 

- (1) provide clearing, delivery, and settlement services 
for ACH entries, as defined by the NACHA Operating 
Rules, between Participating DFIs that have selected 
that ACH Operator to perform ACH services (intra- 
ACH Operator services), and (2) exchange transactions 
with other ACH Operators (inter-ACH Operator 
exchange); 

- process and edit files based on the requirements of the 
NACHA Operating Rules; 

-■ evaluate the credit worthiness of and apply risk control 
measures to their Participating DFIs; 

- adhere to the Federal Reserve's Policy Statement on 
Privately Operated Multilateral Settlement Systems 
(as applicable); and 

- adhere to any National ACH Operator Performance 
Standards of the National Association. 

The primary function of the ACH Operator is to accept 
ACH Files from ODFIs (or other ACH Operators), to sort 
and distribute ACH files to RDFIs (or other ACH 



Operators), and to effect settlement between the financial 
institutions that are parties to the specific transactions. An 
ACH Operator may be a private company or a Federal 
Reserye Bank and may provide services to DFIs on a 
regional or national basis. All ACH Operators are linked 
together for transaction exchange in order to provide a 
nationwide ACH Network accessible to all DFIs. 

ACH Operators provide ACH processing services to DFIs 
under a written agreement or contract. The major 
functions of an ACH Operator are defined by the NA CHA 
Operating Rules; other services are defined in the 
operating agreement between the ACH Operator and 

. DFIs. 

B. ADHERENCE TO NACHA OPERATING RULES 

Each ACH Operator agrees to adhere to the requirements 
of the NA CHA Operating Rules (except when inconsistent 
with the policies or practices of the Federal Reserve 
Banks) and to other applicable laws, regulations, and 
policies governing the transfer of ACH payments. 

C. AGREEMENTS 

Each ACH Operator is required to execute agreements 
with a minimum of twenty independent (i.e., not owned by 
the same holding company) Participating DFIs that bind 
those Participating DFIs to both the ACH Operator's rules 
and to the NACHA Operating Rules, The Federal Reserve 
Bank, however, is not required to bind a Participating DFI 
to any provision of the NACHA Operating Rules that is 
not incorporated by the Federal Reserve Bank's Uniform 
Operating Circular. 

Before participating in the ACH Network, a DFI must 
establish a formal relationship with an ACH Operator. 

1. ELECTRONIC RECORDS AND ELECTRONIC 
RECORD RETENTION 

The NACHA Operating Rules permit ACH participants to 
obtain and store ACH records electronically as an 
alternative to obtaining and retaining such documents in 
hard copy format. Specifically, the Rules allow any 
agreement, authorization, written statement under penalty 
of perjury, or other record required by the NACHA 
Operating Rules to be in writing to be obtained and 
retained in either hard copy or electronic form. 

Electronic Signatures and Records 

Electronic records include agreements, authorizations, 
written statements under penalty of perjury, or other 
records created, generated, sent, communicated, received, 
or stored by electronic means. Electronic records may 
have a signature requirement. 

Electronic signatures are electronic sounds, symbols, or 
processes attached to or logically associated with an 




OG43 



SECTION II - PARTICIPANT RELATIONSHIPS 
CHAPTER III -ACH OPERATORS 



2005 OPERATING GUIDELINES 




agreement, authorization, written statement under penalty 
of perjury, or other record executed or adopted by a 
person with the intent to sign the record. These writing 
and signature requirements can be satisfied by compliance 
with the Global and National Commerce Act (E-Sign 
Act). ACH Operators should be aware that any record 
that is signed according to the terms of an applicable state 
version of the Uniform Electronic Transaction Act is 
considered to have been signed in conformance with the 
terms of the E-Sign Act. 

To satisfy the requirements of the NACHA Operating 
Rules (and Regulation E for preauthorized debits), 
electronic signatures must "similarly authenticate" the 
electronic records. The authentication method chosen 
must evidence both the signer's identity and his assent to 
the terms of the record. For purposes of the NACHA 
Operating Rules, ACH records may also be similarly 
authenticated using the same authentication methods 
currently prescribed for consumer debit authorizations - 
that is, the record may be similarly authenticated via the 
Internet through the use of a digital signature, PIN, 
password, shared secret, etc., or a hard copy record may 
be authenticated via the telephone by the consumer's 
speaking or key-entering a code provided on the record. 

Any other written notice or disclosure required by the 
NACHA Operating Rules but not requiring a signature 
may also be provided in electronic form, including e-mail. 
(This includes the notice for TEL. Please note that state 
and federal laws may require consumer consent before 
using electronic notices/disclosures.) 

Record Retention 

ACH Operators are permitted to retain copies of ACH 
records in electronic form, provided that the electronic 
record ( 1 ) accurately reflects information contained within 
the record, and (2) is capable of being accurately 
reproduced for later reference, whether by transmission, 
printing, or other reproduction. 

ACH Operators choosing to utilize electronic 
communications methods for the retention of ACH 
records should implement practices and procedures to 
ensure that electronic records of ACH documents 
accurately reflect the information contained within the 
document and that both the electronic record and a 
recorded record of the authentication can be accurately 
reproduced for future reference. 

ACH Operators should be aware that other ACH 
participants may also utilize electronic methods to obtain 
and retain records of ACH documents. In such cases, 
ACH Operators can expect to receive electronic versions, 
rather than hard copies, of documents that they request 
from other ACH participants. 



2. RBFIs 

All DFIs participating in the ACH Network must agree at 
a minimum to receive all types of ACH entries -- that is, 
to act as a Receiving DFI. An RDFI may receive files 
from one or more ACH Operators, depending on 
processing and settlement arrangements. An RDFI's 
agreement with one or more ACH Operators will cover, at 
aminimum: 

• delivery arrangements; and 

• ■ settlement arrangements. 

Delivery 

The RDFI will inform the ACH Operator of the Receiving 
Point(s) for file delivery. The RDFI may act as its own 
Receiving Point and receive files directly, or it may 
receive files of ACH entries delivered through another 
financial institution or Third-Party Service Provider that 
acts as its Receiving Point. The Receiving Point should 
be tested by the ACH Operator for its ability to receive 
ACH files. Once a Receiving Point has been tested as a 
valid Receiving Point, more than one RDFI can receive 
ACH activity through it. 

Receiving Points other than financial institutions are 
assigned special Routing Numbers. For information on 
using a Third-Party Service Provider as a Receiving Point, 
see the chapter on Third-Party Service Providers in 
Section IV of these Guidelines. 

Settlement 

The settlement agreement between the RDFI and the ACH 
Operator establishes the process by which settlement 
between these parties will occur. This process 
by ACH Operator, Each RDFI must be familiar with the 
settlement process within its ACH Operator environment. 

In the event that an ODFI is unable to settle transactions 
originated into the ACH Network, the ACH Operator 
would create and transmit reversing entries to the affected 
RDFI(s) for each entry(ies) that cannot settle if that ACH 
Operator's settlement arrangement includes provisions for 
doing so. The description "NONSETTLED" would 
appear in the Company Entry Description field in the 
Company/Batch Header Record. 

3. ODFIs 

In addition to receiving ACH entries, a DFI may also 
choose to participate as an Originating DFI (ODFI) and 
originate entries into the ACH Network under an 
agreement with one or more ACH Operators. Additional 
agreements and testing may be required by each ACH 
Operator before a DFI can begin originating. As in the 
case of an RDFI, the agreements will cover, at a 
minimum: 
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•'.■' delivery arrangements; and 

• settlement arrangements. 

Delivery 

The ODFI will provide information to the ACH Operator 
identifying the source from which files of entries will be 
originated into the ACH Network. The ODFI's Sending 
Point for origination may be the ODFI itself and/or a 
designated Third-Party Service Provider. Sending Points 
other than financial institutions are assigned special 
Routing Numbers. 

An ODFI may originate files through more than one 
Sending Point, and one Sending Point may originate files 
for multiple ODFIs. Sending Points should test file 
exchange with the ACH Operator in order to ensure that 
files of entries can be completely, accurately, and reliably 
exchanged between the Sending Point and the ACH 
Operator. For information on using a Third-Party Service 
Provider as a Sending Point, see the Third-Party Service 
Provider chapter in Section IV of these Guidelines. 

Settlement 

Each ACH Operator establishes settlement and risk 
management procedures for ODFIs. Typically, a DFI 
would have the same settlement agreement for entries 
originated as for entries received. An ODFI that uses 
more than one ACH Operator could be subject to different 
settlement and risk management criteria for each ACH 
Operator. 

Depending on the specific settlement arrangement that an 
ACH Operator has with its participants, the ACH 
Operator would enact the following procedures in the 
event that an RDFI is unable to meet its settlement 
obligation. The ACH Operator would: 

• Create a return (to the ODFI) for each entry that cannot 
be settled; 

• ■ Place the Routing Number of the RDFI in the 

Originating DFI Identification field in the 
Company/Batch Header and Control Records; 

• Place the description "NONSETTLED" in the 
Company Entry Description field of the 
Company/Batch Header Record; and 

• Use the Return Reason Code R32, RDFI Non- 
Settlement. 

In the event that an RDFI is placed under regulatory 
restriction by, for example, a Federal regulator such as the 
FDIC, the participation of the RDFI regarding acceptance 
of ACH activity may be limited (the RDFI is typically 
limited to accepting credit entries only). In this case the 
ACH Operator would take the same steps indicated above, 



except the Return Reason Code R34, Limited 
Participation DFI, would be used. 

D. CLEARING. DELIVERY; AND SETTLEMENT 
SERVICES 

Each ACH Operator controls processing of entries for 
participants based on information contained in a central 
database (Central Information File or Master File). This 
database is the source of all routing and settlement data 
for DFIs participating in the ACH Network. Each profile 
record within the database describes the type and extent of 
participation of each DFI in the ACH Network and 
includes: 

• DFI name; 

•. Routing Number; 

• Settlement information; and 

• Delivery information. 

The Participating DFI profile is determined by the DFI 
based on its status as: a Receiving DFI (RDFI) or an 
Originating DFI (ODFI), its designated Receiving Point(s) 
for delivery of entries from the ACH Operator, which can 
be either the DFI or a designated processor; its designated 
Sending Point(s) for the origination of entries, which 
again may be the DFI or a designated Third-Party Service 
Provider; and the account, either that of the DFI or a 
correspondent DFI, through which settlement for ACH 
entries is to be effected. Each Participating DFI must 
inform its ACH Operator in a timely fashion of any 
changes in its profile that would affect routing or 
settlement of its ACH entries. 

1. ACH OPERATOR SETTLEMENT FUNCTIONS 




Settlement is the actual transfer of value, or funds, 
between financial institutions that have exchanged ACH 
transactions. ACH Operators calculate settlement totals 
owed by and to Participating DFIs based on the effective 
entry and processing dates of batches of transactions 
processed. ACH Operators provide information to 
participants on the dollar amounts that will be settled for 
each institution on each settlement day. ACH entries 
processed by the Federal Reserve ACH Operator are 
settled on the accounts of Participating DFIs at their 
respective Reserve Banks based on settlement instructions 
provided by DFIs. Settlement for transactions processed 
by private ACH Operators may be accomplished privately 
or may be effected by the Federal Reserve on participants' 
reserve accounts (or the reserve accounts of designated 
correspondents) based on settlement totals provided by 
the private sector ACH Operators. 
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2. INTER-ACH OPERATOR EXCHANGE 

When the ODFI and RDFI utilize different ACH 
Operators, more than one ACH Operator must process the 
entry. The Originating ACH Operator is the ACH 
Operator that receives the entry from the ODFI or its 
Sending Point and distributes it to the Receiving ACH 
Operator which, in turn, delivers the entry to the RDFI or 
its Receiving Point. 

Transactions exchanged between private sector ACH 
Operators and the Federal Reserve ACH Operator are 
governed by the interregional deposit and presentment 
times outlined in Federal Reserve Bank Operating 
Circulars. Transactions exchanged among private sector 
ACH Operators are processed within the framework 
established by the private sector ACH Operators. 

3. ACH DATA SECURITY REQUIREMENTS 

For all ACH transactions that involve the exchange or 
transmission of banking information (which includes, but 
is not limited to, an entry, entry data, a routing number, an 
account number, and a PIN or other identification symbol) 
via an Unsecured Electronic Network, the NACHA 
Operating Rules impose specific data security 
requirements for those ACH transactions, regardless of 
the SEC Code contained within the entry. An Unsecured 
Electronic Network is a public or private network that is 
not located entirely within a single, contiguous, physical 
facility and any part of which that has not implemented 
security technologies that provide a level of security that, 
at a minimum, is equivalent to 128-bit RC4 encryption 
technology. 

Specifically, any banking information that is transmitted 
or exchanged via an Unsecured Electronic Network must 
be either ( 1 ) encrypted using a commercially reasonable 
security technology that, at a minimum, is equivalent to 
1 2 8-bit RC4 encryption technology, or (2) transmitted via 
a secure session that utilizes a commercially reasonable 
security technology that provides a level of security that, 
at a minimum, is equivalent to 128-bit RC4 encryption 
technology. Such encryption technology must be 
employed prior to the key-entry and through the 
transmission of any banking information exchanged, via 
an Unsecured Electronic Network, between (1) an 
Originator and a Receiver; (2) an Originator and anODFI; 
(3) an ODFI and an ACH Operator; (4) an ACH Operator 
and an RDFI; and (5) an Originator, ODFI, RDFI, or 
ACH Operator and a Third-Party Service Provider; 

Transmissions or exchanges of banking information using 
voice or keypad inputs from a wireline or wireless 
telephone are not subject to this data security requirement 
unless the telephone is used to access the Internet. An 
application in which the Originator obtains information 
from the Receiver by another means (such as the 
telephone) and then key enters the information via the 
Internet would, for example, be subject to these data 



security requirements. However, information delivered 
via a telephone line, such as a leased line, or dialed into a 
financial institution's modem pool would not be subject to 
this requirement. 

4. DELIVERY OF ACH FILES 

Relationship with ODFI - Input Files 

Origination of entries into the ACH Network is governed 
by rules and format specifications defined in the NACHA 
Operating Rules, local ACH association rules, and various 
ACH Operator agreements. ACH entries must be 
originated in complete files containing one or more 
batches that, in turn, contain one or more entries. For 
additional information on ACH file, batch, and entry 
record formats, see the Mapping chapter in Section IV of 
these Guidelines. 

• Methods of Delivery 



All input files to an ACH Operator must be delivered 
via data transmission. Data transmission options may 
include either dial-up or dedicated communication links 
from ODFIs to the ACH Operator. Each ACH 
Operator provides exact hardware, software, and 
telecommunication protocol specifications for its own 
service, and specifications should be given directly by 
the ACH Operator to ODFIs using its services. 

Input Schedules 

Each ACH Operator establishes processing schedules 
with file input and output deadlines for its Originating 
and Receiving Depository Financial Institutions. 
Deadlines for input of files to the ACH Operator may 
vary, depending on whether the files contain entries that 
must be forwarded to another ACH Operator for 
delivery to the RDFI or if the files contain entries that 
can be processed locally. Deadlines for output of files 
to be delivered to RDFIs may vary depending on the 
ACH Operator's processing environment. Certain 
systems have entries available for distribution 
continuously during the processing day, while others 
prepare entries for distribution at certain defined times 
during the day. 



Relationship with RDFI - Output Files 

Files of entries delivered to RDFIs or their Receiving 
Points conform to the same set of NACHA Operating 
Rules and formatting standards as files originated into the 
ACH system. Files that have been processed and 
distributed by ACH Operators are made available for 
delivery to RDFIs according to each ACH Operator's 
processing schedule and schedule for exchanges with 
other ACH Operators. 
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Methods of Delivery 

As is the case of originated files, output files from the 
ACH Operator can contain multiple batches with each 
batch containing one or more entries. Files of entries 
are delivered by the ACH Operator to the RDFIs or 
their Receiving Points via electronic data transmission. 

Data transmission options may include either dial-up or 
dedicated communications links from RDFIs to the 
ACH Operator. Each ACH Operator provides exact 
hardware, software, and telecommunication protocol 
specifications for its own service, and specifications 
should be given directly by the ACH Operator to 
RDFIs or Receiving Points using its network. 



Output Schedules 



Transmission of output files must be scheduled by the 
RDFI or Receiving Point with its ACH Operator or 
Operators. Depending on the ACH Operator, output 
files may be available for delivery at multiple times 
during the day or at specified predetermined times. 

• Security 

Data security standards are to be in place to ensure that 
data integrity is maintained, between both DFIs and 
ACH Operators and among ACH Operators themselves. 
Each ACH Operator defines various levels of security 
for its participants. 

E. ACH OPERATOR PROCESSING FUNCTIONS 

1. EDITING OF FILES 

Based on the application of NACHA Operating Rules, 
ACH Operators are responsible for the editing of all ACH 
files submitted for processing. ACH file specifications 
are defined in the NACHA Operating Rules, Appendix 
Two. 

ACH files will also be edited for invalid characters. All 
alphameric and alphabetic fields must be left justified and 
space filled. All numeric fields must be right justified, 
unsigned, and zero filled. Characters used in ACH 
records are limited to 0-9, A-Z (both upper and lower 
case), space^ and those special characters which have an 
EBCDIC value greater than hexadecimal "3F" or an 
ASCII value greater than hexadecimal "IF." EBCDIC 
values "OO'^'SF" and ASCII values "00" - "IF" are not 
valid. The use of invalid characters will cause the batch 
that contains the invalid character(s) to reject. 

ACH Operators should have information on the 
processing status of an originated file shortly after receipt 
of the file from the ODFI or Sending Point. At a 
minimum, such status information would indicate whether 
or not the files have successfully passed editing and 
validation routines. Depending on the service offered by 



the ACH Operator, the protocol for delivering the 
acknowledgment could vary. 

Detailed editing described in the paragraphs below is 
performed after initial file validation. The general editing 
philosophy for ACH processing is to accept, route, and 
record appropriate accounting information for all entries, 
provided certain minimum information contained in each 
entry is valid. 

2. FILE ACKNOWLEDGMENTS 



ACH Operator file acknowledgments are available from 
the ACH Operator to the Sending Point indicating that an 
ACH input file was processed. The acknowledgment is a 
file level acknowledgment with batch level reject 
information included. The acknowledgment is available 
to Sending Points as soon as possible after completion of 
the ACH Operator edits. 

At the file level, the ACH Operator makes the following 
minimum information available to the Sending Point: 

• Immediate Origin 

•': Immediate Origin Name (if available) 
•'. File Creation Date 

• File Creation Time (if available) 
:• File ID Modifier 

• File Entry/Addenda Count 

• Total Credit Entry Dollar Amount in File 

• Total Debit Entry Dollar Amount in File 

• File Batch Count 




The acknowledgment will also contain the date and time 
the file was processed by the ACH Operator and, if the 
file was rej ected by the ACH Operator, the reason for the 
rejection. 

If the file was accepted but one or more batches were 
rejected, the ACH Operator makes the following 
information available about each rejected batch: 

• Originating DFI Identification 

• Originating DFI Name (if available) 

• Company Name 

'•' Company Identification 
8 BatchNumber 

• Effective Entry Date 

•' Batch Entry/Addenda Count 

• Total Debit Dollar Amount 
> Total Credit Dollar Amount 

•Reason for Batch Rejection 

3. REJECTION OF FILES, BATCHES, OR 

ENTRIES 

ACH entries sent by ODFIs to ACH Operators can fail 
validation and be rejected at the file, batch, or entry level. 
ODFIs or Sending Points specify to the ACH Operator 
whether their work should be handled on a file or batch 
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level rejection basis. 'Tile level rejection 1 ' means that an 
entire file is rejected if it contains one or more invalid 
batches. "Batch level rejection" means that only the 
invalid batch or batches will be rejected, and the 
remainder of the file will be processed. The ACH 
Operator must notify the Sending Point of rejected files 
and batches. 

File Rejection 

Under several conditions, entire files will be rejected by 
the ACH Operator. It is the responsibility of the ODFI or 
the ODFFs Sending Point, upon notification of rejection, 
to remake and resubmit the file to the ACH Operator. File 
reject conditions are defined in the NA CHA Operating 
Rules, Appendix Three. 

Batch Rejection 

If the ACH Operator is unable to successfully process one 
or more batches within an incoming file, the invalid 
batches will be rejected. If "batch level rejection" has 
been specified, only erroneous batches will be rejected. 
Otherwise, the entire file will be rejected. It is the 
responsibility of the ODFI or the ODFI's Sending Point to 
recreate and resubmit the batches of transactions that were 
rejected by the ACH Operator. Conditions that will cause 
batches to reject are defined in the NACHA Operating 
Rules, Appendix Three. 

Entry Level Rejection 

Individual entries in an ACH file will be rejected by the 
ACH Operator if mandatory information in a record is 
either invalid or missing. Entries rejected by the ACH 
Operator are reformatted as return entries and sent back to 
the ODFI with a Return Reason Code indicating the 
reason for rejection. 



See Appendix Three in the NA CHA Operating Rules for 
detailed information on conditions that will cause files, 
batches, or entries to be rejected by the ACH Operator. 
See the chapter on Returns, Dishonored Returns, 
Contested Dishonored Returns, in Section III of these 
Guidelines for additional information on the return of 
individual entries by an ACH Operator. 

4. SETTLEMENT OF RETURN ENTRIES, 
NOTIFICATIONS OF CHANGE, AND TRC/ 
TRX ENTRIES 

To minimize the potential for float to be created within 
the ACH Network, returns, dishonored returns, and 
contested dishonored returns will be settled by the ACH 
Operator no earlier than the Effective Entry Date 
contained within the original entry, as it appears in the 
return entry Company/Batch Header Record. 

The return of an entry that contains an invalid or stale 
Effective Entry Date will be settled by the ACH Operator 



at the earliest opportunity (i.e., the same banking day of 
processing or next banking day following the processing 
date). For purposes of this section, an Effective Entry 
Date will be considered invalid if the field is blank, zero, 
partially blank or partially non-numeric, or contains an 
incomplete date, day numbers higher than 3 1 , or month 
numbers higher than 12. 

Notifications of Change and TRC/TRX entries will be 
settled at the earliest opportunity (i.e., same banking day 
of processing or next banking day following the 
processing date). 

5. AUDIT TRAILS 

Trace procedures must be available to ODFIs in the event 
that they must attempt to determine an individual 
transaction's status in the ACH system. A transaction may 
have been rejected, delivered to a Receiving Point or 
delivered to another ACH Operator. In any case, there 
must be an audit trail sufficient to trace the incoming 
transaction to its final destination. 

Each ACH Operator will define for its Participating DFIs 
the procedures and information required for tracing an 
entry. Typically, some or all of the following information 
will be required: 

File Header and Control Records : 

• File Creation Date. 
•.' File Creation Time. 

V File ID Modifier. 

• Sending Point Identification. 

• Control Totals (dollar value of file). 

Batch Header and Control Records: 

• Company Name and ID Number. 

• Effective Entry Date. 

Entry Detail Record 

V RDFI Routing Number. 

• Dollar amount of the entry. 

• Trace Number. 

F. EVALUATION OF CREDIT-WORTHINESS 
AND RISK CONTROL MEASURES 

ACH Operators are required by the NA CHA Operating 
Rules to perform an evaluation of the credit worthiness of 
and apply risk control measures to the Participating DFIs 
for which they perform ACH Operator services. 
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G. FEDERAL RESERVE POLICY STATEMENT 

ON PRIVATELY-OPERATED 
:'.-.- MULTILATERAL SETTLEMENT SYSTEMS 

The NACHA Operating Rules require private sector ACH 
Operators to adhere to the Federal Reserve's Policy 
Statement on Privately Operated Multilateral Settlement 
Systems. This Policy Statement addresses risks in 
multilateral settlement arrangements for both small-dollar 
payments, such as clearing houses for checks and ACH 
payments, and for large-dollar payments, which are 
typically used for interbank and financial market 
transactions. 

The Federal Reserve Policy Statement on Privately 
Operated Multilateral Settlement Systems identifies 
fundamental categories of risk, including credit, liquidity, 
operational, legal, and systemic risk, that may arise in 
different types of multilateral settlement arrangements. 
Under this Policy Statement, private sector ACH 
Operators are expected to address any material risks in 
each category. Detailed information on its Policy 
Statement on Privately-Operated Multilateral Settlement 
Systems is available from the Federal Reserve Board. 

H. NATIONAL ACH OPERATOR PERFORMANCE 
STANDARDS 

The NACHA Operating Rules obligate each ACH 
Operator to adhere to any National ACH Operator 
Performance Standards developed by the National 
Association. 



SECTION!! 

PARTICIPANT RELATIONSHIPS 

AND RESPONSIBILITIES 

CHAPTERIV 

RECEIVING DEPOSITORY 
FINANCIAL INSTITUTIONS 

A INTRQDUCTION 

A Receiving Depository Financial Institution (RDFI) is a 
participating depository financial institution that receives 
entries directly or indirectly from its Automated Clearing 
House Operator for debit or credit to the accounts of its 
customers. 

A Receiving Depository Financial Institution's 
responsibilities include the following in regard to receipt 
ofACHfiles: 



timely receipt and validation of all ACH entries; 
proper and timely posting to Receivers' accounts; 
proper and timely validation of prenotifications; 
timely return of entries not posted; 
timely return of prenotification entries; 



• proper notification to Originators of incorrect 
information on accepted entries (Notification of Change 
entries); 

• proper and timely handling of remittance data as 
required by the NACHA Operating Rules; and 

• proper transmission to a Federal Government Agency 
of a consumer's or company's Automated Enrollment 
for a future credit or debit application. 

B;. MEMBERSHIP REQUIREMENTS 

Financial institutions must apply either for membership 
with a regional ACH payment association or for direct 
access participation with the Federal Reserve. 
Membership with a regional ACH payment association is 
recommended to all financial institutions as they can 
benefit from all of the trade association services provided 
by the association, such as: 

• access to current rules and other key information; 

• education and training; and 

• opportunities to become involved in local and national 
issues. 

The following steps are taken to obtain membership with 
an association: 

1 . An application for membership is filed by the 
Receiving Depository Financial Institution (RDFI) 
with the local ACH payment association, including 
me execution of applicable agreements. 

In order to participate in the ACH Network as an 
RDFI, a financial institution must be recognized by 
the Federal Reserve System as a "depository 
institution" as defined in the Federal Reserve Act. 
Institutions that do not fall under that definition (e.g., 
non-bank banks) cannot receive ACH entries directly 
from an ACH Operator but can receive through a 
valid RDFI. 

The application and subsequent agreements provide 
the following information to the ACH payment 
association and the ACH Operator: 

• name and Routing Number of the RDFI; 
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the RDFI's Receiving Point and medium for 
delivery of ACH files; and 

the RDFI's settlement information. The RDFI may 
settle directly with its ACH Operator through a 
correspondent bank relationship. 



2. 



3. 



Testing with an ACH Operator is required to ensure 
the RDFI's designated Receiving Point can accept 
and process ACH files. 

Once testing is completed, the RDFI will be added to 
the ACH Operator's participant master file (Central 
Information File) and the association's membership 
file. 




C. RECEIPT AND PROCESSING OF ACH FILES 

In accordance with the information provided on the 
agreements, the ACH Operator distributes ACH files to 
the RDFI's Receiving Point. A Receiving Point can be the 
RDFI itself or a designated Third-Party Service Provider 
that has entered into an agreement to receive ACH files 
for the RDFI. Even if the Receiving Point is an 
organization other than the RDFI, the 7V/4 CHA Operating 
Rules hold the RDFI (represented by the Routing Number 
in the ACH Entry Detail Record) responsible for all of the 
required functions of the RDFI. This chapter outlines the 
responsibilities of the RDFI. For additional information 
on the use of a third party as a Receiving Point, see the 
chapter on Third-Party Service Providers in Section IV of 
these Guidelines. 

All ACH data sent to an RDFI will be in the required 
ACH file format. Refer to Appendix Two of the NACHA 
Operating Rules or the chapter on Mapping within 
Section IV of these Guidelines. 

1. TRANSACTION CODES 

The NACHA Operating Rules permit Originators to 
transmit ACH credit and debit entries to demand accounts 
(i.e., checking, NOW, and sharedraft accounts) and 
savings accounts at an RDFI. The NACHA Operating 
Rules also permit Originators to transmit both credit and 
debit entries to financial institutions' general ledger 
accounts and to transmit credit entries only (with the 
exception of reversals to correct erroneous debits) to loan 
accounts. 

9 Financial Institution General Ledger Accounts -- Both 
ACH credits and debits may be directed to a financial 
institution's general ledger account. 

As an entry transmitted to a financial institution's 
general ledger account is a corporate transaction, such 
an entry must be properly authorized in accordance 
with the requirements of the NACHA Operating Rules. 
An Originator may not transmit an entry to a financial 
institution's general ledger account unless it has been 



authorized by an agreement with the financial 
institution. RDFIs should work closely with their 
trading partners (e.g., the corporate Originators of 
general ledger transactions) to ensure that they have 
provided them with appropriate routing and account 
number information regarding the general ledger 
account to which the transaction will be transmitted. 

Procedures should be developed by the RDFI to ensure 
that appropriate personnel are given the authority to 
authorize activity to an RDFI's general ledger account. 

The general ledger system of a financial institution is 
equivalent to an account at the financial institution 
belonging to a corporate receiver. For this reason, it is 
essential that RDFIs review their systems to ensure that 
adequate procedures for review of all ACH activity are 
in place when accepting credit and debit activity to 
general ledger accounts. As ACH entries to these 
accounts are corporate in nature, they will be subj ect to 
the same rules and processing requirements governing 
all other corporate transactions (e.g., formatting 
requirements, return time frames, etc.). RDFIs could, 
for example, establish measures to monitor general 
ledger account activity through the generation of daily 
reports for further review by accounting personnel. 

Alternatively, screening mechanisms similar to those 
available for many customer accounts (i.e., debit 
screening) could be established on a general ledger 
account, enabling accounting personnel to enter 
expected transactions into the system prior to their 
receipt so that these transactions are processed without 
the need for additional review. Transactions not 
entered into such a system could be rejected and 
handled as exception items requiring additional review. 
Immediate attention to exception processing will help 
to ensure that returns are processed on a timely basis. 

Other non-programmatic safeguards could include daily 
balancing of general ledger accounts, especially those 
most likely to receive ACH transactions, daily review 
of ACH general ledger transactions, timely processing 
of exception items, and the use and enforcement of 
good internal control procedures. 

Loan Accounts — ACH credit entries are permitted to 
loan accounts belonging to a Receiver. Debit entries to 
loan accounts, with the exception of reversals to correct 
erroneous credit entries, are not permitted. Debit 
entries to loan accounts will be rejected by the ACH 
Operator and returned to the ODFI . Examples of 
applications for which entries will be transmitted to 
loan accounts include consumer bill payments, 
corporate loan payments, and salary allotments. Credits 
to loan accounts will generally represent automated 
loan payments and can be processed in much the same 
manner as internal, "on-us" loan payments. 
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RDFIs must be aware of and monitor specific risk 
management issues relating to the origination of ACH 
activity to loan accounts. Although unlikely, the 
possibility exists for fraudulent debit reversals to be 
transmitted and posted to a credit-only account such as. 
a loan account. To help reduce this risk, RDFIs should 
establish procedures to review loan account activity 
often and return any fraudulent debits as unauthorized. 

Since these types of accounts do not have specific 
statement reporting requirements under Regulation E 
that enable a Receiver to review account activity in a 
timely manner, the statement practices of RDFIs 
concerning such accounts can vary greatly. As a result, 
the Receiver may not become aware of the existence of 
fraudulent ACH debit reversal activity through the 
typical ACH return process or time frames. 

Under these circumstances, inappropriate ACH debit 
reversal activity is not likely to be detected by a 
consumer until he or she receives notice that a loan 
obligation has increased or until a line of credit is 
unavailable for use by the consumer. Although the 
initiation of reversals, as with all ACH origination 
activity, is warranted as appropriate by the ODFI, 
RDFIs may choose to monitor reversal activity to loan 
accounts to ensure that it is appropriate. RDFIs may 
also want to review their statement practices to 
determine whether changes to these practices are 
warranted in response to ACH activity to these 
accounts. The RDFI's practices for notifying 
consumers of changes in obligations to loan accounts 
should also be reviewed to ensure that issues relating to 
electronic activity are addressed. 

With the ability of Originators to originate ACH 
payments to new types of accounts, RDFIs may need to 
evaluate the methods by which ACH routing and 
account information is provided to Receivers. In 
situations where an ACH entry is directed to an account 
other than a demand or savings account, source 
documents for routing and account information 
commonly used by Originators today (i.e., a voided 
check or sharedraft) are unavailable. Originators are 
likely to rely on alternative sources of information, such 
as a loan statement or coupon book, to obtain account 
information. RDFIs may wish to consider providing 
specific ACH routing and account information to their 
loan customers. 

RDFI Acceptance of Entries to General Ledger and Loan 
Accounts 

RDFIs should be aware that, although the NACHA 
Operating Rules prohibit an RDFI from returning an entry 
solely because it is a credit, debit, or zero dollar entry* or 
because it is a particular type of credit, debit, or zero 
dollar entry, the NACHA Operating Rules do permit an 
RDFI to return any entry that concerns an account that is 
not a "transaction account" as defined by Regulation D of 



the Board of Governors of the Federal Reserve System. 
Because loan accounts and general ledger accounts do not 
fall within the Regulation D definition of a "transaction 
account," an RDFI may exercise its right to return any 
payment directed to these accounts using Return Reason 
Code R20 (Non-Transaction Account), provided the 
return entry complies with all rules governing return 
entries. 

2. DELIVERY OF AGH FILES 

ACH Operators deliver files to RDFIs or their designated 
Receiving Points via electronic data transmission. It is 
critical that RDFIs ensure files are received in a timely 
manner. All RDFIs must receive their files in such a 
manner as to ensure fulfillment of their responsibilities for 
posting, funds availability, and timely returns. RDFIs 
must pick up ACH files from ACH Operators in such a 
manner as to ensure compliance with NA CHA Operating 
Rules as well as to meet the need of customers. For 
example, RDFIs are required to provide opening of 
business funds availability on settlement date for 
commercial PPD credits that are made available to the 
RDFI by its ACH Operator by 5:00 p.m. (RDFI's local 
time) on the banking day prior to the settlement date. 
This requirement places the responsibility on the RDFI to 
pick up ACH files that are made available to it by its ACH 
Operator during the afternoon on the banking day prior to 
settlement date and to ensure that the funds are made 
available by opening of business on settlement date. 

3. PROCESSING OF ACH FILES 

Once a file is delivered, the following steps are taken to 
process the file: 

OF AC Regulations 

The U.S. Treasury Department's Office of Foreign Assets 
Control (OF AC) administers economic sanctions and 
embargo programs that require that assets and transactions 
involving interests of target countries, target country 
nationals, and other specifically identified companies and 
individuals be frozen. For purposes of OF AC 
compliance, these entities are called "blocked parties" and 
OF AC maintains and regularly updates a master list of 
"Specially Designated Nationals and Blocked Persons" 
("SDN List") identifying known blocked persons. All of 
the programs involve declarations of national emergency 
by the President of the United States. 

The ACH Network is subject to the requirement to 
comply with OF AC regulations. All U.S. citizens and 
permanent resident aliens, companies located in the U.S., 
overseas branches of U.S. companies, and, in some cases, 
overseas subsidiaries of U.S. companies fall under OF AC 
jurisdiction. In terms of the ACH Network, this means 
that all U.S. ACH participants, including Originators, 
ODFIs, RDFIs, and Receivers need to be aware that they 
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may be held accountable for sanctions violations and must 
understand their compliance obligations. 




Detailed information relating to OF AC Regulations and 
their impact on Originators can be found within Section 
IV, Special Topics, of these Guidelines. 

Data Security 

For all ACH transactions that involve the exchange or 
transmission of banking information (which includes, but 
is not limited to v an entry, entry data, a routing number, an 
account number, and a PIN or other identification symbol) 
via an Unsecured Electronic Network, the NACHA 
Operating Rules impose specific data security 
requirements for those ACH transactions, regardless of 
the SEC Code contained within the entry. An Unsecured 
Electronic Network is a public or private network that is 
not located entirely within a single, contiguous, physical 
facility and any part of which that has not implemented 
security technologies that provide a level of security that, 
at a minimum, is equivalent to 128-bit RC4 encryption 
technology. 

Specifically, any banking information that is transmitted 
or exchanged via an Unsecured Electronic Network must 
be either (1) encrypted using a commercially reasonable 
security technology that, at a minimum, is equivalent to 
128-bit RC4 encryption technology, or (2) transmitted via 
a secure session that utilizes a commercially reasonable 
security technology that provides a level of security that, 
at a minimum, is equivalent to 128-bit RC4 encryption 
technology. Such encryption technology must be 
employed prior to the key-entry and through the 
transmission of any banking information exchanged, via 
an Unsecured Electronic Network, between ( 1 ) an 
Originator and a Receiver; (2) an Originator and an ODFI; 
(3) an ODFI and an ACH Operator; (4) an ACH Operator 
and an RDFI; and (5) an Originator, ODFI, RDFI, or 
ACH Operator and a Third-Party Service Provider. 

Transmissions or exchanges of banking information using 
voice or keypad inputs from a wireline or wireless 
telephone are not subject to this data security requirement 
unless the telephone is used to access the Internet. An 
application in which the Originator obtains information 
from the Receiver by another means (such as the 
telephone) and then key enters the information via the 
Internet would, for example, be subject to these data 
security requirements. However, information delivered 
via a telephone line, such as a leased line, or dialed into a 
financial institution's modem pool would not be subject to 
this requirement. 

Verification of Identity of Originators 



The NA CHA Operating Rules also require ODFIs to 
utilize commercially reasonable methods to establish the 
identity of each Originator that uses an Unsecured 
Electronic Network, such as the Internet, to enter into a 



contractual relationship with the ODFI for the origination 
of ACH transactions. Such a requirement helps to ensure 
that ODFIs employ measures to know the Originators with 
whom they establish relationships over Unsecured 
Electronic Networks and to verify those Originators' 
identities. 



File Editing 



When the output file is received from the ACH Operator, 
the RDFI must edit the file to ensure that: 

• the file can be read; 

> the file has been received correctly (has been directed 
to the appropriate RDFI); 

• the file is properly formatted; 

.•■ (if used) the file message authentication code (MAC) 
calculated agrees with the MAC sent by the originating 
organization; and 



.•■'. the detail entries balance with the internal and external 
control totals. If not, the ACH Operator should be 
notified immediately and a remake requested. 

These editing procedures are essential to all RDFIs 
regardless of the delivery mechanism. 

RDFI File Processing 



ACH output files can include any combination of the 
following: 

• prenotification entries; 

• . ■ . entries returned by the ACH Operator as unprocessable 
(including returns or notifications of change); 

• returns and notifications of change (ODFIs only); 

■• debit entries for settlement same day or next day; and 

.• credit entries for settlement same day, riGxt day, or in 
two days. 

Most RDFIs process ACH files through an automated 
posting system. Automated processing will also result in 
the generation of daily activity reports . These reports will 
indicate: 

• the entries that have successfully posted to Receivers' 
accounts; 

v the entries that did not post (exception items); and 

• prenotification entries. 
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Following is a checklist for RDFIs to Follow when 
processing ACH files: 

• Entries must be posted as of Settlement Date (found in 
the Company/Batch Header Record), not the Effective 
Entry Date. Warehousing may be required. 

• The account number should be edited, if necessary, for 
proper posting. 

RDFIs must accept an ACH entry when it bears the 
account number as obtained from the on-us field of 
their checks or sharedrafts. An RDFI should utilize the 
notification of change process to request a change in 
me account number. 



RDFIs should review the on-us field of their checks or 
sharedrafts to determine whether or not adjustments 
will need to be made to handle ACH entries that carry 
account information obtained from that source. 
Modifications to receiving software may be required so 
that entries bearing information contained in the on-us 
field can be posted to the customer's account without a 
delay in funds availability. If the on-us field contains 
a check sequence number or other data which the 
financial institution uses for internal processings the 
institution's ACH software must recognize these codes 
and not reject an ACH entry based on their presence. 
Internal edits based on the on-us field of a financial 
institution's check or sharedraft that extract the account 
number for ACH processing may also be necessary. 

The proper information should be carried through to the 
customers' statements to satisfy . descriptive 
requirements. RDFIs should be aware that there may be 
state laws regarding privacy that impact what 
information may be provided on a consumer's periodic 
statement. For example, at least one state prohibits 
financial institutions from printing Social Security 
Numbers on consumers' bank account statements that 
are sent via the U.S. Postal Service, requiring financial 
institutions in that state to establish procedures to 
ensure that such information is not being passed 
through and printed on the consumers' statements. 
Because laws concerning privacy regulations are 
dynamic and are regularly undergoing change, RDFIs 
are strongly encouraged to stay abreast of developments 
in this area. 

All data is received in ACH record formats and should 
be generated on the ACH daily activity report or stored 
in machine processable format as it was received to 
allow for proper creation of returns and notifications of 
change. 

All addenda records must be identified and processed 
appropriately. 



Addenda Record Processing 

All ACH entries (each Standard Entry Class Code) except 
ARC, POP, RCK, TEL, TRC and XCK can carry an 
addenda record(s). The RDFI must be able to identify 
these addenda and react appropriately. Following is a 
chart that shows how the RDFI might expect to see 
addenda records that may accompany those entries. 



Entry 

Prenotification 
Entries 

Entries returned by the 
ACH Operator as 
unprocessable. 

Returns and NOCs 



Debit entries 



Credit entries 



Automated Enrollment 
Entries 



Destroyed Check Entries 



Use of Addenda Records 
Do not typically include addenda. 



These are return entries that 

carry an addenda containing 

the return information 

All carry addenda with return 
or change information. 

All Standard Entry Class Codes 

except ARC, POP, RCK, TEL, 

TRC, and XCK can carry addenda. 

All Standard Entry Class 
Codes can carry addenda. 

All carry addenda with enrollment 

information to be used by 

Federal Government agencies. 

Do not include an addenda record. 




The NACHA Operating Rules require that, upon the 
request of the Receiver, an RDFI must provide to each 
Receiver all payment-related information contained within 
the addenda records transmitted with CCD, CTX, and CIE 
entries. RDFIs must have procedures in place to respond 
to requests from Receivers that desire to receive payment- 
related information transmitted with these entries. RDFIs 
must provide the Receiver with the requested information 
by the opening of business on the second banking day 
following the settlement date of the entry to which the 
payment-related information relates. The requirement that 
an RDFI provide payment-related information contained 
within the addenda records of CCD, CTX, and CIE entries 
applies to those payments received after the request is 
made by the Receiver. The provision of payment-related 
addenda record information relating to payments received 
prior to the Receiver' s request is at the discretion of the 

Kpn,.;;;;-;:;;;;'.:^ 

The method by which the payment-related information is 
provided to the Receiver is not prescribed by the NACHA 
Operating Rules. Instead, the medium to be used is to be 
determined by the RDFI and the Receiver. RDFIs are 
encouraged, in conjunction with their customers, to 
determine the method by which the addenda record 
information will be provided, i.e., either in human- 
readable or machine-readable format. If the addenda 
record information will be provided in human-readable 
format, the RDFI must ensure that the addenda 
information is translated from ANSI ASC XI 2 syntax or 
a NACHA-endorsed banking convention and provided to 
the Receiver in human-readable text. If the addenda 
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record information will be provided in machine-readable, 
electronic file format (i.e., computer-to-computer data 
transmission), the RDFI and Receiver will need to 
determine whether the information will be (1) transmitted 
to the Receiver as a pass-through of the electronic file 
format (i.e., in ANSI ASC X12 syntax or NACHA- 
endorsed banking convention), (2) translated into a 
proprietary format agreed to by the RDFI and Receiver, or 
(3) merged with the Receiver's lockbox data. 

For more information on addenda records, refer to the 
chapter on Addenda Records in Section IV of these 
Guidelines. 

Frenotifications and Exception Handling 




Prenotifications - the RDFI must recognize 
prenotifications and is required to respond to 
prenotifications when appropriate. Response to a 
prenotification, when appropriate, is fulfilled by the return 
or notification of change process. 

Exception Handling - Entries that do not post to 
Receivers' accounts are exception items that must be 
identified and processed by the RDFL When an entry 
does not post, the RDFI must either: 

• manually post the entry; 

• manually post the entry and initiate a notification of 
change; or, 

■• return the entry. 

Exception items must not be suspended at the RDFI - they 
must be posted on a timely basis or returned in the proper 
time frame. 



For more information on prenotifications, returns, and 
notifications of change, see Section III, Functional 
Responsibilities, of these Guidelines. 

Destroyed Check Entries (XCKV 

It is possible that an RDFI will receive entries bearing the 
Standard Entry Class Code XCK. These are entries that 
an ODFI has chosen to initiate in order to collect checks 
which have been irretrievably lost or destroyed. 
Acceptance of XCK entries by the RDFI is voluntary. 
The RDFI may choose not to accept any XCK entries. In 
this case, the RDFI will need to recognize the entries as 
XCK entries and ensure that returns are initiated utilizing 
the Return Reason Code R33, Return of XCK Entry. The 
RDFI must recognize that the original check no longer 
exists; therefore, if the XCK entry is returned, the ODFI 
will likely recreate the item for collection through the 
check clearing system. 

If the RDFI does choose to accept XCK entries, it could 
do so under the following scenarios: 



.• The RDFI could choose to simply allow the XCK 
entries to post with no special handling; Those entries 
that do not post would be returned. 

• The RDFI could choose to modify its software, 
particularly for corporate accounts, to handle XCK 
entries. This would allow the entries to "cross over" 
from the ACH processing stream to the check 
processing stream for such purposes as account 
reconciliation, balance reporting, etc. 

RDFIs that accept XCK entries must be aware that they 
are required to print the contents of the Check Serial 
Number Field on the consumer's monthly bank account 
statement. RDFIs should examine their statement 
reporting software to ensure this information is included 
as part of the monthly bank account statement. 

Use of the ACH for the collection of irretrievably lost or 
destroyed checks affords some benefit to the RDFI in that 
the collection process is accomplished more quickly and 
with fewer errors. The RDFI would not have to handle 
copies of the original items: 

There are some disadvantages to the RDFI, whether or not 
the RDFI chooses to accept XCK entries. For the RDFI 
that chooses not to accept XCK entries, the primary 
disadvantage is the necessity to recognize and return the 
items. RDFIs that choose to accept XCK entries could 
experience the following disadvantages: 

• Customer inquiries regarding these entries could occur 
and procedures would need to be established for 
handling the inquiries. (NOTE: The financial 
institution could receive customer inquiries even if the 
XCK entry was returned, since the original check will 
never be presented.) 

'■•.'■ The RDFI will need to handle some returns. 

° The RDFI could identify a need for special handling of 
corporate accounts. 

In making a determination whether or not to accept XCK 
entries, the RDFI needs to weigh the advantages and 
disadvantages of handling an XCK entry versus the 
advantages and disadvantages of handling a copy of the 
original item, since the original check has been destroyed, 
and will not be presented. 

For complete information on XCK entries, refer to the 
Destroyed Check Entry chapter within Section IV of these 
Guidelines. 

Death Notification Entries (DNE) 

Death Notification Entries are entries bearing the 
Standard Entry Class Code DNE and are designed to 
provide RDFIs with a clear, easily identifiable means of 
notification that an RDFI's customer has died. The entries 
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are initiated into the ACH Network by a Federal 
Government agency, such as the Social Security 
Administration, and have no settlement value (the dollar 
amount is zero, and the Transaction Code is the same as 
it would be for a prenotification entry). Because specific 
responsibilities and liabilities are associated with benefit 
payments received after notice of the death of a 
beneficiary, it is critical that financial institutions take 
advantage of every opportunity to learn of an account 
holder's death. 

DNE entries are provided electronically via the ACH; 
therefore, the efficiency of the death notification process 
can be significantly increased. An RDFI that receives a 
DNE entry may act more quickly to stop and return credit 
entries that have been or will be initiated to a customer 
that is deceased. By doing so, the RDFI could (1) reduce 
losses resulting from the inappropriate withdrawal of 
funds by joint account holders and (2) eliminate the need 
for the Originator of a payment to rely on the reclamation 
process for some entries. 

Currently^ the initiation of Death Notification Entries is 
limited to Federal Government agencies that originate 
monthly direct deposit payments. By providing electronic 
notice via the ACH to an RDFI of a customer's death 
within 24 hours of the report being received by the 
Federal Government agency, the length of time in which 
notice of death is provided to the RDFI can be reduced by 
up to two weeks. The standard method of notification to 
a financial institution, the TFS-133, Notice of 
Reclamation, can take weeks longer to be received by the 
RDFI and may add to the RDFI's liability. 

Benefits of Receiving Death Notification Entries 

Receipt of a Death Notification Entry can provide a 
number of benefits to an RDFI: 

• By notifying an RDFI of the death of one of its 
customers more quickly, the RDFI may take steps to 
reduce its exposure to loss resulting from the 
withdrawal of funds after the beneficiary's death by a 
joint account holder. 

• RDFI resources currently used to process Government 
reclamation actions could be reduced or reallocated. 

• The number of reclamations produced by the U.S. 
Department of the Treasury's Financial Management 
Service (FMS) could be reduced, thus saving the RDFI 
processing costs. 

• RDFIs could set up a stop-payment type of process 
under which future credit entries to a deceased 
beneficiary's account would be automatically returned. 

• RDFIs would be able to limit their losses due to 
reclamations. 



RDFFs Responsibilities Concerning Death Notification 
Entries 

An RDFI has a number of different options for handling 
a DNE entry. 

'• An RDFI could take no action. The RDFI would incur 
no additional costs by this action; however, its exposure 
to loss may increase since receipt of a DNE entry is 
considered to be official notice of death. 

.'• An RDFI may implement manual procedures for 
handling DNE entries. Although the RDFI's operating 
costs may increase under this option, such an increase 
could be offset by the decreased costs associated with 
the processing of paper reclamations, since fewer paper 
reclamations would be received by financial 
institutions. 

• An RDFI may choose to modify its software to "flag" 
a deceased recipient's account so that a stop-payment 
may be placed on the account and all subsequent credit 
entries returned. Although this option might require a 
one-time expense for software modification, these costs 
may be offset by a reduction in losses and costs 
associated with handling paper reclamations. 

Information Contained in DNE Entries 

Each Death Notification Entry is clearly identifiable as a 
notice of death by the Standard Entry Class Code "DNE" 
and always contains zeros in the Amount field. A DNE 
entry also includes the nine-digit Social Security Number 
and alphameric subscript code under which the deceased 
recipient was being paid in the Individual Identification 
Numberfield. 

All DNE entries include an addenda record. The 
information contained in the addenda record consists of 
the following human-readable data: (1) the date of the 
customer's death, (2) the customer's own Social Security 
Number (this may or may not be the same as the Social 
Security Number contained in the Entry Detail Record), 
and (3) the amount of the next payment. This information 
is contained within a fixed field format and may be 
machine-processed if the RDFI so desires. 

Format of the Payment Related Information Field of the 
Addenda Record 

DATE OF DEATH*MMDDYY*CUSTOMER SSN* 
#########* AMOUNT*$$$$.CC\ 

Example : DATE OF DEATH*032892*CUSTOMER 
SSN*012345678*289.25\ 

The actual date of death always appears in positions 18- 
23. If the Social Security Number is not available, 
positions 38-46 will contain zeros. The amount of the 
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expected beneficiary payment always begins in position 

55. .■ 

Acknowledgment Entries (ACK, ATX) 




RDFIs may choose to provide ACH acknowledgment 
services to their corporate Receivers. An Originator may 
request an acknowledgment by the RDFI that a corporate 
credit entry (CCD or CTX entry) has been received by the 
RDFI. 

ACH acknowledgment entries are optional, non-dollar 
transactions that may be used by an RDFI to acknowledge 
that a corporate ACH credit entry has been received and 
that the RDFI will attempt to post the payment to the 
Receiver's account. RDFIs choosing to offer 
acknowledgment services to their corporate Receivers will 
need to develop the capabilities to identify and process 
acknowledgment requests for acknowledgment entries on 
behalf of their customers and to identify and react to 
refused acknowledgment entries in the event that the 
acknowledgments are misrouted or erroneous. For 
additional information on how to utilize the ACH 
acknowledgment process, see the Acknowledgment Entry 
chapter in Section III of these Guidelines. 

Cross-Border Entries 

The CBR and PBR Standard Entry Class Codes must be 
used for the transmission of cross-border ACH credit and 
debit entries. The CBR Standard Entry Class Code is 
used for the transmission of corporate cross-border 
entries, and the PBR Standard Entry Class Code is used 
for the transmission of consumer cross-border 
transactions/These Standard Entry Class Codes allow 
cross-border transactions to be readily identified by 
financial institutions so that they may apply special 
handling requirements for cross-border payments, as 
desired. These formats enable ACH participants to 
transmit and receive detailed information that is unique to 
cross-border payments. 

The cross-border formats utilize a unique Company/Batch 
Header Record to convey information relating to foreign 
exchange, origination and destination currencies, and 
destination country. Each CBR and PBR Entry Detail 
Records is accompanied by one mandatory addenda 
record, within which information relating to the foreign 
receiving DFI, foreign payment amount, foreign trace 
number, and foreign receiver's account number is 
conveyed. 

For CBR and PBR return entries, unique Company/Batch 
Header Records and Addenda Records accommodate the 
return of cross-border-specific information. The Entry 
Detail Record used for cross-border returns is the same 
format used for all other returns but has been expanded to 
accommodate cross-border information. 



A unique Company/Batch Header Record also exists for 
cross-border dishonored returns, contested dishonored 
returns, NOCs, and refused NOCs. The existing Entry 
Detail Records and Addenda Records for dishonored 
returns, contested dishonored returns, NOCs, and refused 
NOCs have been expanded to accommodate cross-border 
payments. 

For additional information relating to Cross-Border 
Payments, refer to Section IV within these Guidelines. 
For specific information on formatting requirements and 
technical specifications associated with the new CBR and 
PBR Standard Entry Class Codes, refer to the NACHA 
Operating Rules. 

Point-of-Purchase Entries 

A Point-of-Purchase (POP) entry is a Single-Entry ACH 
debit entry, initiated by an Originator (i.e., a merchant, 
biller, etc.) to a consumer's account for the in-person 
payment for goods or services. These one-time debit 
entries are initiated by the Originator based on a written 
authorization and account information obtained from the 
source document (check) obtained from the consumer at 
the point-of-purchase. The source document, which is 
voided by the merchant and returned to the consumer at 
the point-of-purchase, is used to collect the consumer's 
routing number, account number, and check serial number 
that will be used to generate the debit entry to the 
consumer's account. For detailed information on POP 
entries, refer to the Point of Purchase Entries chapter 
within Section IV of these Guidelines. 



Accounts Receivable Entries 

An Accounts Receivable (ARC) Entry is a Single-Entry 
ACH debit used by Originators to convert a consumer 
check that is received via the U.S. mail or at a dropbox 
location for the payment of goods or services. With the 
ARC application, the consumer's check is viewed solely 
as source document, from which the consumer's routing 
number, account number, check serial number, and dollar 
amount for the transaction will be captured for use in the 
ACH debit entry. 

For detailed information on ARC entries, refer to the 
Accounts Receivable Entries chapter within Section IV of 
these Guidelines. 

Re-presented Check Entries 

A Re-presented Check (RCK) Entry is a Single-Entry 
ACH debit entry used by Originators (merchants, billers, 
etc.) as an alternative method of collecting checks that 
have been returned because of insufficient or uncollected 
funds. This method of collection via the ACH Network, 
when compared to the check collection process, provides 
Originators with the potential for improvements to 
processing efficiency (such as control over timing of the 
initiation of the debit entries) and decreased costs. For 
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detailed information on Re-presented Check Entries, see 
Section IV of these Guidelines. 

Internet-Initiated Entries 

The WEB (Internet-Initiated Entry) Standard Entry Class 
Code is required to be used by Originators initiating debit 
entries (both recurring and Single-Entry) to a consumer 
account pursuant to an authorization that is obtained from 
the Receiver via the Internet. This SEC Code is intended 
to address unique risk issues that are inherent to the 
Internet payment environment through requirements for 
added security procedures and obligations. For detailed 
information on originating WEB entries, see the chapter 
on Internet-Initiated Entries within Section IV of these 
Guidelines. 

Telephone-Initiated Entries 

Originators of Single-Entry debits to consumer accounts 
may obtain an oral authorization for such an entry from 
the consumer via the telephone. These Single-Entry 
debits, which must utilize the TEL Standard Entry Class 
Code, may only be originated when either (1) there is an 
existing relationship between the Originator and the 
Receiver, or (2) there is no existing relationship between 
the Originator and the Receiver, but the Receiver has 
initiated the telephone call. For detailed information on 
originating TEL entries, see Section IV of these 
Guidelines. 

4. MANUAL PROCESSING OF ACH FILES 

Non-automated RDFIs must manually post the ACH 
entries to customers' accounts. This method is not 
preferred; however, RDFIs that must post manually 
should, at a minimum, arrange for delivery of the payment 
information in a timely manner. Many options are 
available for RDFIs to have ACH files delivered 
electronically even if the file must be converted to paper 
for manual posting. It is possible that an RDFI utilizes a 
third party to receive files electronically, but the third 
party converts the file to paper for processing by the 
RDFI. It is critical that the RDFI receive this irrformation 
from the third party in a time frame that will allow the 
RDFI to comply with all of the rules regarding funds 
availability, returns, etc. 

5. EXCUSED DELAY 

The provisions within the NACHA Operating Rules with 
respect to excused delay help to clarify circumstances in 
which a processing delay by a Participating DFI or ACH 
Operator would be excused. In certain circumstances, a 
delay in acting on an ACH entry may result in a loss to a 
Participating DFI. In these situations, it-is necessary to 
allocate such a loss among the Participating DFIs. 

For example, if an RDFI delays the return of an ACH 
debit entry to the ODFI, and the ODFI is unable to charge 



the transaction back to the Originator because the 
Originator has become insolvent, the delay will result in 
a loss to the ODFI. When the return is due to insufficient 
funds rather than a breach of the ODFFs warranty that the 
entry is authorized, the RDFI will ultimately incur this 
loss unless the delay is excused in accordance with the 
NACHA Operating Rules. 

DFI and ACH Operator operational outages due to the 
general failure or interruption of communication or 
computer facilities or other equipment do not constitute an 
excused delay. In other words, DFIs and ACH Operators 
should expect that computer problems will occur and 
should make contingency plans to handle such situations. 
In this regard, the NACHA Operating Rules governing 
excused delay are consistent with general guidance from 
the Federal Financial Institutions Examination Council 
(FFIEC) regarding contingency backups, which states that 
"All computer installations must make formal 
arrangements for alternative processing capability..." 

Although the NA CHA Operating Rules governing excused 
delay require backup systems to protect DFIs and ACH 
Operators from delays caused by computer failure, the 
failure of a DFI's or ACH Operator's systems due to 
circumstances beyond their control may still constitute an 
excused delay, provided that such diligence as the 
circumstances require is exercised. 

D. POSTING AND FUNDS AVAILABILITY 

It is the responsibility of the RDFI to post entries and 
make funds available when appropriate. Posting and 
funds availability are determined by the Settlement Date 
in the Company/Batch Header Record, not the Effective 
Entry Date. 

ACH debits will be made available to an RDFI no earlier 
than one banking day prior to the Settlement Date. 
NACHA Operating Rules state that debits CANNOT be 
posted prior to the Settlement Date. 

If a Receiving DFI is closed for business on the scheduled 
Settlement Date of a debit entry, but the Receiving ACH 
Operator is open, the Receiving DFI will be debited on 
the scheduled Settlement Date unless it has advised the 
ACH Operator to delay settlement until the next business 
day of the Receiving DFI. If the ACH Operator agrees to 
delay settlement, the Receiving DFI must pay for any float 
resulting from the deferral of settlement 




ACH credits will be available to Receiving Points from 
the ACH Operator no earlier than two banking days prior 
to the Settlement Date. It is recommended that credits be 
posted or at a minimum, memo posted, prior to opening of 
business on Settlement Date; however, credit entries could 
be posted prior to the Settlement Date if the RDFI cannot 
warehouse the entry. (The RDFI should consider the 
effect of posting credits and making funds available to the 
Receiver prior to the date on which the RDFI receives 
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settlement for those credits.) Regulation E and NACHA 
Operating Rules require that credit entries be made 
available for cash withdrawal by the customer on the 
settlement day. 

PPD credit entries made available to an RDFI by its ACH 
Operator by 5:00 p.m. (RDFFs local time) on the banking 
day prior to the Settlement Date must be made available 
to the Receiver for withdrawal or cash withdrawal at the 
opening of business on the Settlement Date of the entry. 
An entry or entry data is made available to an RDFI or its 
receiving point when the entry or entry data is processed 
by the RDFFs ACH Operator and is ready for distribution. 
"Opening of business" is defined as the later of 9:00 a.m. 
(RDFFs local time) or the time the RDFFs teller facilities 
(including ATMs) are available for customer account 
withdrawals. If the Receiver's account can be accessed at 
the RDFI through an ATM prior to 9:00 a.m. (RDFFs 
local time), PPD credit entries must be made available for 
withdrawal or cash withdrawal at 9:00 a.m. (RDFFs local 
time) on the settlement date. If the Receiver's account 
cannot be accessed at the RDFI through an ATM prior to 
the opening of the RDFFs teller facilities, and the RDFFs 
teller facilities open at 9:00 a.m. or later (RDFFs local 
time), these PPD credit entries must be made available for 
withdrawal or cash withdrawal when the RDFFs branch 
facilities are open for customer transactions. For 
example, if branch facilities open at 10:00 a.m., these 
PPD credit entries must be made available for withdrawal 
or cash withdrawal at 10:00 a.m. If branch facilities open 
at 9:00 a.m., these PPD credits must be made available for 
withdrawal or cash withdrawal at 9:00 a.m. An RDFI can 
satisfy its obligation to make a credit entry available for 
cash withdrawal by a specific time by making the entry 
available for cash withdrawal at a teller or an ATM by 
that time. RDFIs should realize that these are the 
minimum requirements for making funds available. It is 
recommended that RDFIs make PPD credit entries 
available at both the ATM and teller facilities at opening 
of business. 

For all other credit entries, including PPD credit entries 
that are made available to an RDFI after 5 :00 p.m. 
(RDFI ' s local time) on the banking day prior to settlement 
date, RDFIs are required to make funds for these entries 
available for withdrawal or cash withdrawal on settlement 
date. An RDFI can satisfy its obligation to make such a 
credit entry available to a Receiver for cash withdrawal on 
the settlement date by making the entry available for 
withdrawal at the RDFFs teller facilities by the close of 
business on the settlement date or at an ATM by midnight 
on the settlement date. 

An RDFI is responsible for picking up ACH files that are 
made available to it by its ACH Operator during the 
afternoon. An RDFI that uses a receiving point is 
responsible for making sure that the receiving point picks 
up files that are made available by the ACH Operator 
during the afternoon and for ensuring that funds are made 
available by opening of business on settlement date. 



If posting has not occurred prior to Settlement Date, an 
RDFI should have alternative procedures in place such as 
checking the history of customer data or examining the 
customer's credit notification in order to make funds 
available to the customer. 

E. ACCOUNTING AND SETTLEMENT 



When an ACH file is processed by the receiving ACH 
Operator, the ACH Operator will read the Effective Entry 
Date in the Company Batch Header Record and settle 
accordingly. If the file has been delivered to the ACH 
Operator appropriately and the ACH Operator can settle 
on the Effective Entry Date, it will insert the 
corresponding Julian Date in the Settlement Date field. If 
the ACH Operator cannot settle on the Effective Entry 
Date due to a stale date, weekend or holiday, the ACH 
Operator will insert a Julian Date into the Settlement Date 
Field reflecting settlement on the next available business 
day.-; .■.■■■.■■■■'.■■. 



V Settlement information is produced as ACH entries are 
processed by ACH Operators. This information is 
accumulated based on the type of entry (debit or credit) 
by Settlement Date. These settlement totals are 
reported to the RDFI or its settlement member 
correspondent. 

• The ACH Operator may provide ACH settlement 
information in machine-readable format to facilitate the 
automation of settlement accounting for correspondent 
RDFIs. 

• Settlement totals should be balanced daily againsttotals 
posted to the RDFFs customers' accounts and against 
any rejects that occur. Rej ects and other differences 
must be resolved immediately. 

• ACH settlement procedures are the same for consumer 
and corporate transactions; however, in view of the 
large dollar entries that flow through the ACH Network 
for corporate customers, an RDFI should have internal 
procedures in place for monitoring large dollar 
settlement totals. Notification to the RDFFs "money 
desk," daylight overdraft reporting, and customer 
verification are examples to be considered. 

Non-Settlement 

In some ACH operating environments, it is possible that 
settlement for ACH activity could be reversed due to the 
failure of the ODFI to meet its settlement obligations. 
The RDFI needs to be familiar with the policies 
established by ACH Operators for settlement finality. For 
additional information, see the ACH Operators chapter in 
Section II of these Guidelines. 
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F. AUTHORIZATIONS AND AGREEMENTS 

1. ELECTRONIC RECORDS AND ELECTRONIC 

: : RECORD RETENTION .'■ :;■ 

The NA CHA Operating Rules permit ACH participants to 
obtain and store ACH records electronically as an 
alternative to obtaining and retaining such documents in 
hard copy format. Specifically, the Rules allow any 
agreement, authorization, written statement under penalty 
of perjury, or other record required by the NA CHA 
Operating Rules to be in writing to be obtained and 
retained in either hard copy or electronic form. 

Electronic Signatures and Records 

Electronic records include agreements, authorizations, 
written statements under penalty of perjury, or other 
records created, generated, sent, communicated, received, 
or stored by electronic means. Electronic records may 
have a signature requirement 



Record Retention 



Electronic signatures are electronic sounds, symbols, or 
processes attached to or logically associated with an 
agreement, authorization, written statement under penalty 
of perjury, or other record executed or adopted by a 
person with the intent to sign the record. These writing 
and signature requirements can be satisfied by compliance 
with the Global and National Commerce Act (E-Sign 
Act). RDFIs should be aware that any record that is 
signed according to the terms of an applicable state 
version of the Uniform Electronic Transaction Act is 
considered to have been signed in conformance with the 
terms of the E-Sign Act. 

To satisfy the requirements of the NACHA Operating 
Rules (and Regulation E for preauthorized debits), 
electronic signatures must "similarly authenticate" the 
electronic records. The authentication method chosen 
must evidence both the signer's identity and his assent to 
the terms of the record. For purposes of the NACHA 
Operating Rules, ACH records may also be similarly 
authenticated using the same authentication methods 
currently prescribed for consumer debit authorizations - 
that is, the record may be similarly authenticated via the 
Internet through the use of a digital signature, PIN, 
password, shared secret, etc., or a hard copy record may 
be authenticated via the telephone by the consumer's 
speaking or key-entering a code provided on the record. 

Any other written notice or disclosure required by the 
NA CHA Operating Rules but not requiring a signature 
may also be provided in electronic form, including e-mail. 
(This includes the notice for TEL. Please note that state 
and federal laws may require consumer consent before 
using electronic notices/disclosures.) 



RDFIs are permitted to retain copies of ACH records in 
electronic form, provided that the electronic record (1) 
accurately reflects information contained within the 
record, and (2) is capable of being accurately reproduced 
for later reference, whether by transmission, printing, or 
other reproduction. 



RDFIs choosing to utilize electronic communications 
methods for the retention of ACH records should 
implement practices and procedures to ensure that 
electronic records of ACH documents accurately reflect 
the information contained within the document and that 
both the electronic record and a recorded record of the 
authentication can be accurately reproduced for future 
reference. 

RDFIs should be aware that other ACH participants may 
also utilize electronic methods to obtain and retain records 
of ACH documents. In such cases, RDFIs can expect to 
receive electronic versions, rather than hard copies, of 
documents that they request from other ACH participants. 

2. CORPORATE ENTRIES 

RDFIs that receive corporate transactions to their 
corporate accounts should have an understanding with the 
Receiver as to the nature of the transactions and the level 
of information processing expected by the Receiver. 
Corporate entries can be simple, i.e., represent the transfer 
of funds only, or can be complex, i.e., contain significant 
amounts of payment-related data. Various levels of 
service regarding information processing and account 
status can be offered to corporate Receivers. Some levels 
of service may require extensive contracts and agreements 
between the Receiver and the RDFL 

Unauthorized Corporate Entries 

The RDFI may wish to provide various levels of service 
to Receivers regarding debit activity to an account. A 
Receiver may choose to disallow all debit activity to an 
account, with the exception of reversals to correct 
erroneous transactions, or it may ask the RDFI to monitor 
activity to an account to ensure that no unauthorized debit 
activity is posted. The RDFI must ensure that a return 
entry for an unauthorized debit to a corporate account is 
transmitted in such a time and manner that it is received 
by the RDFFs ACH Operator by its deposit deadline for 
the return entry to be made available to the ODFI no later 
than the opening of business on the second banking day 
following the settlement date of the original entry. Return 
Reason Code R2 9 , Corporate Customer Advises Not 
Authorized, is used for the return of such an unauthorized 
debit. RDFIs should note, however, that this Return 
Reason Code is intended to be used for the return of one 
unauthorized debit only and does not imply the revocation 
of authorization with the Originator. 
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If a Receiver notifies an RDFI that a CCD or CTX debit An unauthorized debit does not include a debit entry 
to its business account was not authorized, and the time initiated with fraudulent intent by the Receiver or any 
frame for returning the debit has expired, the RDFI may person acting in concert with the Receiver, nor does it 
contact the ODFI and request that the ODFI accept a include ACH transactions that were properly authorized 
return entry beyond the allowed time frame. If the ODFI but the goods or services received were not satisfactory to 
refuses to accept the return, and the Receiver maintains its the consumer, 
claim that the entry was not authorized, the Receiver or 

the RDFI could pursue the matter outside the parameters Consumer debit entries returned by the RDFI as 
of the ACH return process. A corporate Receiver may unauthorized will bear Return Reason Code RIO 
also request that the RDFI return unauthorized credit (Customer Advises Not Authorized, Notice Not Provided, 
entries to its account. For more information, refer to the Improper Source Document, or Amount of Entry Not 
Returns, Dishonored Returns, Contested Dishonored Accurately Obtained from Source Document) and must be 
Returns chapter within these Guidelines. returned by the RDFI in such time and manner that the 

return is made available to the ODFI no later than the 
3. CONSUMER ENTRIES opening of business on the banking day following the 

sixtieth calendar day following the Settlement Date of the 
The RDFI is not required to keep a file of authorizations original entry. This return deadline also applies to debit 
for consumer transactions. The RDFI may rely on the entries for which the consumer Receiver had previously 
warranties of the ODFI, which is responsible for ensuring revoked his authorization for the transaction (Return 
the authorization is in place. A copy of the authorization Reason Code R07 - Authorization Revoked), 
may, however, be requested by the RDFI from the ODFI 

both before and after receipt of an ACH entry. This At times, Originators may erroneously transmit ACH 
request is normally limited to resolution of disputes and is entries that are formatted using an incorrect SEC Code. 
not done on a routine basis. When such a copy is This is in violation of the NACHA Operating Rules. 
requested by an RDFI, the ODFI is required to provide the Because the Rules require the RDFI to rely on the ODFFs 
copy to the RDFI within ten banking days and at no warranty that the SEC Code included in the entry is 
charge. proper, the RDFI is obligated to use the return rules and 

time frames associated with that particular SEC Code. 
Currently, an unauthorized debit to a consumer account 
where that entry incorrectly bears a corporate SEC Code 
must be returned in accordance with the return rules and 
time frames governing corporate transactions (that is, 
using Return Reason Code R29 within two banking days 
of the Settlement Date of the original entry). In such 
cases, the RDFI is typically precluded from automatically 
returning such an unauthorized debit because the return 
time frame for corporate entries will have lapsed before 
the consumer can receive his statement and notify his 
RDFI about the unauthorized debit to his account. 
Instead, the RDFI would be required to request 
permission from the ODFI to return the entry as a 
permissible return. 



Unauthorized/Improper Consumer Entries 

Consumers have the right to notify the RDFI that an ACH 
transaction (typically a debit) was not authorized or 
relates to an authorization that had been revoked, was 
ineligible for origination as an ACH entry, or was 
improperly originated. The RDFI should establish 
procedures to ensure that customer service personnel are 
aware of the RDFI's responsibilities in this regard (see the 
chapter on Returns, Dishonored Returns, and Contested 
Dishonored Returns in Section III of these Guidelines). 

Unauthorized Debit Entries 



A debit is unauthorized when: 

• the written authorization requirements have not been 
followed; 



a transaction was initiated in an amount greater than 
that authorized by the Receiver; 

a transaction was initiated for settlement earlier than 
authorized by the Receiver; or 

with respect to ARC entries, (1) notice was not 
provided to the Receiver by the Originator in 
accordance with the requirements of the NACHA 
Operating Rules, (2) the entry was transmitted to an 
account of a Receiver who opted out of ARC check 
conversion activity, or (3) the amount of the ARC entry 
was not accurately obtained from the source document. 



Effective March 18, 2005, a new Return Reason Code 
R05 (Unauthorized Debit to Consumer Account Using 
Corporate SEC Code) will become available to RDFIs for 
the return of unauthorized debits transmitted to consumer 
accounts when those debit entries incorrectly bear a 
corporate SEC Code (i.e., CCD, CTX, or CBR). With the 
addition of this rule, the RDFI will be permitted to return 
all unauthorized debits to consumer accounts, regardless 
of SEC Code, within sixty days of the Settlement Date of 
the original entry, provided the RDFI has obtained a 
written statement under penalty of perjury from the 
consumer. 
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Ineligible/Improper Consumer Debit Entries 

RDFIs may also return entries that were ineligible for 
ACH origination or that were originated improperly. An 
ineligible or improper debit entry is an entry for which: 

8 Ineligible RCK Entries: 

- the item to which the entry relates is ineligible to 
be initiated as an RCK entry (Return Reason Code 

■■■:■:::■ rsi);::/::-::: -./^ 

- the required notice stating the terms of the re- 
presented check entry policy was not provided by 
the Originator in accordance with the requirements 
of the NA CHA Operating Rules (Return Reason 
CodeRSl); 

- all signatures on the item to which the RCK entry 
relates are not authentic or authorized, or the item 
has been altered (Return Reason Code R5 1); 

- the amount of the RCK entry was not accurately 
obtained from the item (Return Reason Code 
R51);or 

'■■■—: both the RCK entry and the item to which the 
RCK entry relates have been presented for 
payment (Return Reason Code R53). 

•Improper ARC Entries; 

- the source document used for the debit entry is 
improper (Return Reason Code RIO): 

- checks drawn on corporate or business 
accounts; 

- third-party checks; 

.-.'■ demand drafts/third-party drafts that do not 
contain the signature of the Receiver; 

- credit card checks; 

- obligations of a financial institution (travelers 
checks, cashier's checks, official checks, money 
orders, etc.) 

- checks drawn on the U.S. Treasury, a Federal 
Reserve Bank^ or a Federal Home Loan Bank; 

- checks drawn on a state or local government; 

- checks payable in a medium other than United 
States currency. 

- the source document was presented for payment 
(Return Reason Code R37). 

• Ineligible POP Entries; 

.— the source document used for the debit entry is 
improper (Return Reason Code RIO): 

- checks drawn on corporate or business accounts; 

- third-party checks; 



- credit card checks; 

- obligations of a financial institution (travelers 
checks, cashier's checks, official checks, money 
orders, etc.) 

-.; checks drawn on the U.S. Treasury, a Federal 
Reserve Bank, or a Federal Home Loan Bank; 

- checks drawn on a state or local government; 

- checks payable in a medium other than United 
States currency; 

- previously voided checks/sharedrafts used for 
prior POP entries. 

- the source document was presented for payment 
(Return Reason Code R3 7). 

The RDFI must obtain a written statement under penalty 
of perjury from its customer prior to initiating a return for 
an entry that the customer claims is unauthorized, 
ineligible or improper, or for which the authorization has 
been revoked. An RDFI may refer to the specific 
definition of what constitutes an unauthorized entry in its 
evaluation of a consumer's claim that an entry was not 
authorized. (NOTE: Account holders do not necessarily 
have to sign the written statement under penalty of perjury 
in person at the financial institution.) 

An RDFI must establish internal procedures to obtain 
written statements under penalty of perjury when 
necessary. By initiating the adjustment entry for the 
transaction in question, the RDFI warrants that it has 
obtained a written statement under penalty of perj ury from 
the consumer. The RDFI indemnifies each ODFI, ACH 
Operator, and ACH Association against any claims, 
demands, loss, liability, or expense resulting from the 
breach of this warranty. The RDFI is required to provide 
the ODFI with a copy of the Receiver's written statement 
under penalty of perjury within sixty days of the date on 
which it receives the ODFI's written request for a copy, 
provided that the request is received by the RDFI within 
one year of the date of the initiation of the adjustment 
entry. (NOTE: It is recommended that the RDFI choose 
an ACH contact person for inclusion in the ACH 
Participant Directory who is familiar with the bank's 
procedures governing written statements under penalty of 
perjury. This contact person is likely to receive written 
requests and telephone calls concerning this process and 
should be prepared to handle these inquiries. A sample 
written statement under penalty of perjury is included 
within this chapter for reference.) 

RDFIs should be aware, when recrediting their consumers 
for unauthorized or improper debit entries, that the 
requirement to obtain a written statement under penalty of 
perjury is the minimum requirement under the NACHA 
Operating Rules. An RDFI may choose, at its discretion, 
to obtain an affidavit from its account holder. For 
purposes of the NACHA Operating Rules, a written 
statement under penalty of perjury or affidavit is not 
required to be notarized. 
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G. AUDIT REQUIREMENTS 

All RDFIs and any Third-Party Service Providers 
performing a function of ACH processing on behalf of 
those RDFIs are required to perform an annual audit to 
determine compliance with the rules regarding the receipt 
of ACH entries . Under the NA CHA Operating Rules, 
each RDFI warrants the completion of the rules 
compliance audit by both of these participants. Both 
RDFIs and their Third-Party Service Providers must retain 
documentation supporting the completion of an audit of 
ACH rules compliance for a period of six years from the 
date of the audit and must provide such documentation to 
the National Association upon request. RDFIs should be 
aware that such documentation will not be asked for in an 
arbitrary or capricious manner; rather, proof of an audit 
will be requested only when deemed reasonably necessary 
by the National Association. Acceptable documentation 
may include, but is not limited to, a letter from an internal, 
outside or independent auditor indicating satisfactory 
performance of all audits. 

The NACHA Operating Rules require all RDFIs and any 
Third-Party Service Providers performing a function of 
ACH processing on behalf of those RDFIs to perform an 
annual audit that addresses the specific requirements listed 
below. When conducting an annual audit, RDFIs must 
understand that these audit provisions do not prescribe a 
specific methodology to be used for the completion of an 
audit but identify key rules provisions that should be 
examined during the audit process. RDFIs should rely on 
the guidance of their auditors with respect to the specific 
auditing practices and procedures that must be followed. 

• Verify that records of entries, including return and 
adjustment entries, transmitted from or to an ACH 
Operator are retained for six years from the date the 
entry was transmitted. RDFIs and Third-Party Service 
Providers will also be required to verify that a printout 
or reproduction of the information relating to the entry 
can be provided to the Participating D.FF.s customer or 
any other Participating DFI or ACH Operator that 
originated, transmitted, or received the entry. 

• Verify, when electronic records are used, that such 
records (1) accurately reflect information contained 
within the record, and (2) are capable of being 
accurately reproduced for later reference, whether by 
transmission, printing, or otherwise. 

•■ Verify that prenotifications received are for valid 
accounts and that when a prenotification is not 
processable or is erroneous, the prenotification is 
rejected on a timely basis through the use of return 
entry procedures or that changes are requested through 
the Notification of Change procedure. " 

• Verify that, subject to the RDFI's right of return, all 
types of ACH entries and prenotifications are accepted. 



Review records and procedures to ensure that: 

'— the amount of consumer credit entries is made 
available for withdrawal or cash withdrawal no later 
than the date of settlement, 

- for PPD credits, the amount of the PPD credit is 
made available for withdrawal or cash withdrawal at 
the opening of business on Settlement Date whenever 
possible. For PPD credit entries made available to 
the RDFI by 5:00 p.m. (RDFI's local time) on the 
banking day prior to settlement date, funds are made 
available for withdrawal or cash withdrawal no later 
than opening of business on settlement date. RDFIs 
should pick up files that are made available to them 
by their ACH Operators during the afternoon on the 
day before Settlement Date in order to ensure 
compliance with the rules governing funds 
availability for PPD credit entries. 

- that debit entries are not posted prior to Settlement 
Date. 

Verify that the RDFI sends or makes available as part 
of the account statement for consumer customers the 
minimum descriptive information concerning each 
credit or debit entry consistent with the requirements of 
Appendix Four (Minimum Description Standards.) For 
ARC, POP, RCK, and XCK entries, verify that the 
RDFI also provides the contents of the Check Serial 
Number Field on the consumer's statement/Also verify 
that the RDFI sends or makes available, as part of the 
account statement for consumers, the contents of the 
Terminal City Field and Terminal State Field with 
respect to POP entries. 

For all entries except RCK, review records and 
procedures to determine that return entries, including 
rejected prenotifications, are received by the RDFI's 
ACH Operator by its deposit deadline for the return 
entry to be made available to the ODFI no later than the 
opening of business on the second banking day 
following the Settlement Date of the original entry. 
"Second banking day" refers to the second banking day 
of the RDFI's ACH Operator, and "Settlement Date of 
the original entry" refers to the Settlement Date of the 
original entry that is being returned. 

Review records and procedures to ensure that 
dishonored return entries received by the RDFI are 
handled appropriately, and that contested dishonored 
return entries and corrected returns are initiated in a 
timely manner. 

Review internal procedures and customer agreements 
to ensure compliance with UCC Article 4A. (Note: 
This requirement is with respect to ACH transactions 
only.) 



OG62 



2005 OPERA TING GUIDELINES 



SECTION II - PARTICIPANT RELATIONSHIPS 

_^__^__ CHAPTER IV r -RDFIs 



• Review records and procedures to ensure that written 
statements under penalty of perjury are obtained from 
consumers for all returns bearing Return Reason Codes 
R07, RIO, R37, R51, and R53, and that each 
adjustment entry is received by the RDFFs ACH 
Operator by its deposit deadline for the adjustment 
entry to be made available to the ODFI no later than the 
opening of business on the banking day following the 
sixtieth calendar day following the settlement date of 
the original entry. Verify that copies of written 
statements under penalty of perjury are provided to the 
ODFI within the required time frame, when such copies 
are requested by the ODFI in writing. 

r Verify that, with the exception of NOCs due to merger 
or acquisition, Notifications of Change are transmitted 
within two banking days of the settlement date of the 
entry to which the NOC relates. 

• Review records and procedures to ensure that, when 
requested to do so by the Receiver, the RDFI provides 
all payment-related information transmitted with CCD, 
CIE, and CTX entries to the Receiver by the opening of 
business on the second banking day following the 
settlement date of the entry. 

1 Review internal procedures to ensure that the return of 
an RCK entry is transmitted to the RDFFs ACH 
Operator by midnight of the second banking day 

following the banking day of receipt of the presentment 
notice. 

Review internal procedures to ensure that, for each 
RCK entry for which a stop payment has been placed 
on the item to which the RCK entry relates and for each 
ARC entry for which a stop payment order has been 
placed on the source document to which the ARC entry 
relates, the adjustment entry is received by the RDFFs 
ACH Operator by its deposit deadline for the 
adjustment entry to be made available to the ODFI no 
later than the opening of business on the banking day 
following the sixtieth calendar day following the 
settlement date of the original entry. (Note: No written 
statement under penalty of perjury is required for 
entries returned for these reasons.) 

Review internal procedures to verify that, for consumer 
entries except ARC, POP, RCK, TEL, and Single-Entry 
WEB entries, the RDFI has acted on stop payment 
orders placed with the RDFI at least three banking days 
prior to the scheduled date of the transfer. For 
corporate entries, as well as for ARC, POP, RCK, TEL, 
and Single-Entry WEB entries, verify that the RDFI has 
acted on stop payment orders that have been received 
in such time and in such manner that allow the RDFI to 
act on the stop payment order prior to acting on the 
debit entry; 



H. RULES ENFORCEMENT 
Rules Enforcement Process 



The National System of Fines defined by the NACHA 
Operating Rules is intended to maintain the quality of 
ACH services and the satisfaction of Participating DFIs 
and their customers by ensuring compliance by 
Participating DFIs with the requirements of the NACHA 
Operating Rules. A party to an ACH transaction may 
utilize the rules enforcementprocess to address a violation 
of the NACHA Operating Rules. For complete 
information on the requirements governing the National 
System of Fines and the submission of a Report of 
Possible ACH Rules Violation, refer to Section IV of 
these Guidelines. 
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Sample Written Statement Under Penalty of Perjury 

Stateof :■■■■■■'■ 

County of 

I s . .- ... : . .-: •■■■■ ..-■ :-..•■ . ■-. ■ ■■ ■ ■' ■:■■■, state that I have examined the attached statement or other notification from 
[Bank] indicating that an ACH debit entry was charged to my Account No. ■■.■.:'■■■ . ■ ; , on 

,20 in the amount of $ '■' : : ■■, and that the debit was unauthorized or improper. 

An unauthorized debit (with the exception of TEL entries) means an electronic fund transfer from a consumer's 
account initiated by a person who was not authorized by the consumer, via a writing that was either signed or similarly 
authenticated, to initiate the transfer. With respect to TEL entries, an unauthorized debit means an electronic fund 
transfer from a consumer's account initiated by a person who was not authorized by the consumer, via an oral 
authorization, to initiate the transfer. An electronic fund transfer in an amount greater than that authorized by the 
consumer or that results in a debit to the consumer's account earlier than that authorized by the consumer also is an 
unauthorized debit. An unauthorized debit does not include an electronic fund transfer initiated with fraudulent intent 
by the consumer or any person acting in concert with the consumer. An improper debit means a Re-presented Check 
Entry [RCK], Point-of-Purchase Entry [POP], or Accounts Receivable Entry [ARC] that meets the criteria described in 
Section II below. 

I. For unauthorized entries, I further state that: (check one) 



I did not authorize, and have not ever authorized. (company name) 

to originate one or more ACH entries to debit funds from any account at [Bank]. 

I authorized : - '■ '• ' ■' ' ■ " ■ ■ ■'■ (company name) to originate one or more ACH entries to 

debit funds from my account, but on ■' ■■■ : ■■■ •■ ■; 20_ I revoked that authorization by notifying 
in the manner specified in the authorization. 

I authorized ■' ■■■ ■ ■ ■'■ - • ' ■••■'' to originate one or more ACH entries to debit funds 
from an account at [Bank] but 

the amount debited exceeds the amount I authorized to be debited. The 



amount I authorized is $_ 



.■ OR 

the debit was made to my account on a date earlier than the date on which 
I authorized the debit to occur. I authorized the debit to be made to my accounton 
or no earlier than , 20 . 

II. For improper entries , I further state that: (check one) 

• for RCK entries: 

the item to which the entry relates is ineligible to be initiated as an RCK entry; 

the required notice stating the terms of the re-presented check entry policy was not provided by the 

Originator in accordance with the requirements of the NACHA Operating Rules; 

all signatures on the item to which the RCK entry relates are not authentic or authorized, or the item 

has been altered; 

. the amount of the RCK entry was not accurately obtained from the item; or 

both the RCK entry and the item to which the RCK entry relates have been presented for payment. 
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• for ARC entries: 

_____ notice was not provided by the Originator in accordance with the requirements of the NACHA 
Operating Rules; 

the source document used for the debit entry is improper; 

_____ both the source document and the ARC entry to which it relates have been presented for payment; or 

_____ the amount of the ARC entry was not accurately obtained from the source document. 

* for POP entries: 

___ the debit entry for which the Receiver is seeking recredit was not authorized by the Receiver; 

_____ the source document used for me debit entry is improper; or 

_____ both the source document and the POP entry to which it relates have been presented for payment. 

I further state that the debit transaction was not originated with fraudulent intent by me or any person acting in 
concert with me, and that the signature below is my own proper signature. 

I certify under penalty of perjury that the foregoing is true and correct. 



DateandPlace Signature 



NOTE: RDFIs should consult with their own legal counsel and rely on their own business judgment in 
determining what specific form the written statement under penalty of perjury should take. 
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PRENOTIFICATIONS 




A. INTRODUCTION 

A prenotification is a non-dollar entry sent through the 
ACH Network by an Originator to an RDFI. It conveys 
the same information (with the exception of the dollar 
amount and transaction code) that will be carried on 
subsequent entries, and it allows the RDFI to verify the 
accuracy of the account data. This chapter addresses the 
responsibilities of the Originator, ODFI, and RDFI in 
handling prenotifications. 

B. RESPONSIBILITIES OF ORIGINATORS 
1. PRENOTIFICATION 



Use of the prenotification process by an Originator is 
optional for all Standard Entry Class Codes. Since the 
prenotification process helps to ensure that subsequent 
entries to a Receiver's account at an RDFI are posted 
appropriately, an Originator may, at its option, initiate a 
prenotification entry for any ACH transaction. In 
choosing to transmit prenotification entries, however, an 
Originator must fulfill all other requirements relating to 
prenotifications as provided for within the NA CHA 
Operating Rules and as outlined below. 

2. TIMING OF ORIGINATION 

A prenotification entry may be originated at any time. If 
an Originator chooses to transmit prenotification entries, 
however, it may not initiate live dollar entries until at least 
six banking days following the settlement date of the 
prenotification entry. The prenote must carry an 
appropriate Effective Entry Date to be processed through 
the ACH system (it. is. not the date of the first live entry). 
Any prenotification entry with an Effective Entry Date 
that falls outside of the processing window will be 
rejected by the ACH Operator just as it would if it were a 
live entry. 

3. FORMAT REQUIREMENTS 

The format of a prenotification entry is the same as a live 
dollar entry, except in the Entry Detail Record, in which 
the dollar amount is zero and the transaction code 
indicates a prenotification entry. Prenotification entries 
may be intermingled within a batch of credit and/or debit 
live dollar entries. 



4. RESPONSE TO PRENOTIFICATION 
RETURNS AND NOTIFICATIONS OF 
CHANGE 

There are three ways that an Originator can receive a 
response to a prenotification. The prenotification can be: 

• returned by the ACH Operator as unprocessable; 
■• returned by the RDFI; or, 

• result in the origination of a Notification of Change 
(NOC) from the RDFI. 

These methods of return and notification of change are 
addressed completely in the chapters relating to 
Notifications of Change and Returns, Dishonored Returns, 
and Contested Dishonored Returns in Section III of these 
Guidelines. However, the following checklist is provided 
to Originators specifically for the origination of 
prenotifications: 

• IF A PRENOTIFICATION is returned by the ACH 
Operator, THEN THE ORIGINATOR SHOULD be 
aware that the RDFI has never received the prenote. 
The Originator should research the reason for the return 
and make any necessary corrections before transmitting 
another entry. 

vIF A PRENOTIFICATION is returned by the RDFI, 
THEN THE ORIGINATOR SHOULD research the 
problem according to the Return Reason Code 
contained on the return entry and make any necessary 
corrections prior to transmitting a subsequent entry. 

• IF A PRENOTIFICATION results in a Notification of 
Change, THEN THE ORIGINATOR SHOULD make 
the required change within six banking days of receipt 
of the NOC information or prior to initiating another 
entry, whichever is later, or issue a Refused 
Notification of Change. 

C. RESPONSIBILITIES OF QDFIs 

1. ORIGINATION OF PRENOTIFICATIONS 

Under the NACHA Operating Rules, an ODFI is subject 
to various warranties regarding entries it has originated 
and, accordingly, may incur liability for actions of an 
Originator that result in breaches of the ODFI's warranty. 
The prenotification process provides some protection to 
the ODFI and Originator in that it places the responsibility 
of verifying account data on the RDFI. ODFIs may enter 
into agreements with Originators which transfer liability 
incurred by the ODFI under the NACHA Operating Rules 
to the Originator. Under such an agreement, Originators 
that choose not to send prenotification entries are 
responsible for entries that are misrouted to incorrect 
accounts. Prenotification responsibilities should be 
clearly outlined in any agreement between the ODFI and 
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Originator and in any supporting training material 
provided to the Originator by the ODFI. 

2. RETURNED PRENOTIFICATIONS/ 
NOTIFICATIONS OF CHANGE 

Any response to a prenotification, either from the ACH 
Operator or the RDFI, will be sent to the ODFFs 
Receiving Point: ODFIs will receive these entries in the 
same file as other ACH entries received on any day. 
Responses to prenotifications in the form of a return or 
Notification of Change are always sent to the ODFI's 
ACH Receiving Point, regardless of the point from which 
the prenotifications were originated (such as a Third-Party 
Service Provider). 

The ODFI must ensure that: 

• its receiving software recognizes responses to 
prenotifications (returns and NOCs); 

• all pertinent data regarding prenotification returns and 
NOCs is forwarded to the Originator in a timely 
manner; 

• policies and procedures are established for Refused 
Notifications of Change and disputed returns; 

.'• its originating companies are familiar with the data 
being sent to them; and, 

• '■ its originating companies are aware of their 
responsibilities in handling these entries. 

P. RESPONSIBILITIES OF RDFIs 

1. RECEIVING AND IDENTIFYING 
PRENOTIFICATIONS 



Prenotifications can be received in any ACH file on any 
day with live entries or zero dollar entries. 

The RDFI can process prenotifications immediately 
upon receipt and need not warehouse the entry. These 
are non-dollar entries and have no accounting impact. 

RDFIs can identify prenotifications by Transaction 
Code in the Entry Detail Record. Transaction Codes 
for prenotifications are: 

23 Prenotification for DDA credit. 

28 Prenotification for DDA debit. 

33 Prenotification for Savings credit. 

38 Prenotification for Savings debit. 

43 Prenotification for General Ledger credit. 

48 Prenotification for General Ledger debit. 

53 Prenotification for Loan Account credit. 



2. PROCEDURES FOR HANDLING 
PRENOTIFICATIONS 

The RDFI should be aware that use of the prenotification 
process by Originators is optional for all Standard Entry 
Class Codes. However, the RDFI must verify the 
accuracy of the account number for all prenotification 
entries it receives and should also verify the account type 
(checking, savings, general ledger, loan). If the Individual 
Name on the entry is not the name on the account, the 
RDFI may rely solely on the account number for posting 
purposes. 



The RDFI can take one of three courses of action when it 
receives a prenotification: 

•. Accept the prenotification if the account information is 
correct - no further action is required. 

• Notify the Originator that it will not accept the live 
entry by returning the prenotification. The information 
on the prenotification is incorrect and the correct 
information is not available. 

• Notify the Originator by originating a Notification of 
Change that it will accept the live entries, but certain 
information is incorrect and needs to be changed on the 
subsequent live entry(ies). 

In order to process the prenotification properly, the RDFI 
must have: 

• all of the payment information that was originated on 
theprenote; 

• procedures in place for comparing the payment 
information with its customer account information; and 

• procedures in place for initiating returns and 
Notifications of Change. 

For complete instructions on how to initiate returns and 
Notifications of Change, refer to the chapters relating to 
Notifications of Change and Returns, Dishonored Returns, 
and Contested Dishonored Returns in Section III of these 
Guidelines. 

3. TIMING OF RESPONSES TO 
PRENOTIFICATIONS 

Returns initiated in response to prenotifications are 
subject to the same rules that govern all returns. See the 
chapter on Returns, Dishonored Returns, and Contested 
Returns in Section III of these Guidelines for detailed 
information. 
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SECTION III 

FUNCTIONAL RESPONSIBILITIES 

CHAPTERTI 

NOTIFICATIONS OF CHANGE 

A. INTRODUCTION 

A Notification of Change (NOC) is a non-dollar entry 
transmitted by an RDFI to the ACH Operator for 
distribution back to the Originator through the ODFL It 
is created when the RDFI receives a prenotification or a 
live dollar entry that contains incorrect information. A 
Notification of Change fulfills the following purposes: 

° identifies the entry that has been received at the RDFI; 

• pinpoints the specific information on that entry that is 
incorrect; and 

•'; provides the correct information in a precise format so 
the Originator can make the change. 

Notifications of Change have a unique Standard Entry 
Class Code, COR, and a unique Addenda Type Code, 
"98". This chapter addresses the responsibilities of the 
RDFI, ODFI, and Originator regarding Notifications of 
Change. 

B. RESPONSIBILITIES OF RDFIs 

L ORIGINATION OF NOTIFICATIONS OF 

;■'■'; CHANGE : ; ' - 

Receiving Depository Financial Institutions are required 
to fulfill certain responsibilities when receiving ACH 
entries (see the chapter on RDFIs in Section II of these 
Guidelines). One component of those responsibilities is 
the initiation of a Notification of Change when 
appropriate. A Notification of Change should be initiated 
when: 

• a prenotification is received that contains incorrect 
information; or, 

•' a live dollar entry is received that contains incorrect 
information. 

A Notification of Change entry must be transmitted by the 
RDFI within two banking days of the Settlement Date of 
the entry to which the NOC relates, except when the NOC 
is initiated as a result of a merger, acquisition, or other 
similar event. 



An entry can contain incorrect information when: 

• incorrect information was obtained by the Originator 
during the enrollment process; or, 

• information regarding the account or account holder 
changes at the RDFI. 

2. REASONS FOR CHANGE 



The reasons for which an RDFI will initiate a Notification 
of Change are categorized by specific Change Codes. The 
examples given below for each code are not intended to 
exclude other situations in which a specific code might be 
used. 

€01 Incorrect DFI Account Number. The Account 
Number structure is not valid. For example, the 
Originator uses the on-us field of a check or sharedraft to 
obtain the account number, but additional or fewer 
characters are needed to post the ACH entry. The account 
number could also be incorrect due to the transposition of 
characters, etc. The Correct Account Number appears in 
the first (left justified) 17 positions of the Corrected Data 
Field. For outbound cross-border entries, the correct 
Foreign Receiver's Account Number will appear in the 
first (left justified) 25 positions of the Corrected Data 
Field. 



€02 Incorrect Routing Number. Due to merger or 
consolidation, a once- valid Routing Number must be 
changed. The Correct Routing Number (including Check 
Digit) appears in the first nine positions of the Corrected 
Data Field. For outbound cross-border entries, this field 
will refer to the Originating Gateway Operator's routing 
number. 



€03 Incorrect Routing Number and Incorrect DFI 
Account Number. Due to merger or consolidation, a 
once- valid Routing Number and Account Number must be 
changed. This code could also be used when the 
Originator obtains both the Routing Number and the 
Account Number from the MICR encoding on a check or 
share draft, and both are invalid for ACH entries (payable- 
through information). The Correct Routing Number 
(including Check Digit) appears in the first nine positions 
of the Corrected Data Field. The Correct Account 
Number appears in the 13 th through 29 th positions of the 
same field with a space in the 1 th , 1 1*, and 12 th positions. 
This code should not be used for outbound cross-border 
entries due to field length limitations. 

€04 Incorrect Individual Name/Receiving Company 
Name. The Individual Name field on the entry needs to 
be changed. The Correct Account Name appears in the 
first 22 positions of the Corrected Data Field. 
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COS Incorrect Transaction Code. The entry is being 
directed to the wrong type of account. For example, a 
savings account transaction code is needed, but a demand 
account transaction code is being used, or vice versa. The 
Correct Transaction Code appears in the first two 
positions of the Corrected Data Field. 

C06 Incorrect DFI Account Number and Incorrect 
Transaction Code. A once-valid Account Number and 
Transaction Code must both be changed; for example, an 
entry posting to a savings account should actually be 
going to a demand account or vice versa, and the account 
number is also incorrect. The correct Account Number 
appears in the first (left justified) 17 positions of the 
Corrected Data Field; the correct Transaction Code 
appears in the 21 st and 22 nd positions of the same field 
with spaces in the 1 8 th , 1 9 th , and 20 th positions. For 
outbound cross-border entries, the correct Foreign 
Receiver's Account Number will appear in the first (left 
justified) 25 positions of the Corrected Data Field. The 
correct Transaction Code will appear in the 28 th and 29 th 
positions of the same field, with spaces in the 26 th and 27 th 
positions. 

C07 Incorrect Routing Number, Incorrect DFI Account 
Number, and Incorrect Transaction Code. The Routing 
Number, Account Number, and Transaction Code are all 
incorrect and must be changed; for example, an entry 
posting to a savings account should actually be going to a 
demand account or vice versa, and the Routing Number 
and account number are also incorrect. The correct 
Routing Number (including Check Digit) appears in the 
first nine positions of the Corrected Data Field; the correct 
Account Number appears in the 1 0th through 26 th 
positions of the same field; the correct Transaction Code 
appears in the 27 th and 28 th positions of the same field. 
This change code should not be used for outbound cross- 
border entries due to field length limitations. 

C08 Incorrect Foreign Receiving DFI Identification. 

This Change Code is used to indicate an Incorrect Foreign 
Receiving DFI Identification for CBR and PBR entries. 
The correct Foreign Receiving DFI Identification appears 
in the first (left justified) 11 positions of the Corrected 
Data Field. 

C09 Incorrect Individual Identification Number. 

Individual's account number with the Originator is 
incorrect. The Correct Account Number appears in the 
first 22 positions of the Corrected Data Field. ( NOTE : 
This Change Code is used for CIE, MTE, POS, and SHR 
entries only. Before using this Code, the RDFI should 
verify the Standard Entry Class Code on the original 
entry. The information identified by this code (Individual 
ID Number) has a different meaning for these applications 
than the same field in other applications.) 



NOTE : Change Code C09 is used for CIE, 
MTE, POS, and SHR entries only. Before using 
this Code, the RDFI should verify the Standard 
Entry Class Code on the original entry. The 
information identified by this code (Individual ID 
Number) has a different meaning than the same 
field in other applications. 



C13 Addenda Format Error. Information in the Entry 
Detail Record was correct and the entry was able to be 
processed and posted by the RDFI. However, information 
found in the Addenda Record was unclear or was 
formatted incorrectly. Example: An entry is received 
with an "05" Addenda Type Code, but the addenda 
information does not contain ANSI ASC XI 2.4 data 
segments or a NACHA endorsed banking convention. 

3/ TIMING OF ORIGINATION 

The purpose of a Notification of Change is to provide the 
Originator with information before the origination of the 
subsequent entry. In order to accomplish that goal, the 
RDFI should establish procedures for the immediate 
handling of exception items that require an NOC. NOCs 
must be transmitted by the RDFI within two banking days 
of the Settlement Date of the entry to which the NOC 
relates. It is not necessary for NOCs originated due to a 
merger, acquisition, or other similar event to be initiated 
within that time frame. 

4. FORMAT REQUIREMENTS 

The preferred method of originating Notifications of 
Change is in automated format; however, the RDFI may 
do so in a non-automated manner if the RDFFs ACH 
Operator provides a service to convert the non-automated 
NOCs to automated format. Regardless of the medium on 
which a Notification of Change is originated, the 
following guidelines apply: 

: • ■ The amount field is always zero. If the RDFI wishes to 
effect settlement, it must return the entry to which the 
NOC relates (see the chapter on Returns, Dishonored 
Returns, and Contested Dishonored Returns in Section 
III of these Guidelines). 

■v ■ The original payment information must be sent with the 
Notification of Change. Regardless of what 
information is being corrected, it is essential that the 
RDFI include all of the information on the Notification 
of Change entry as it was sent on the original entry so 
the ODFI and Originator can identify the entry. In 
some cases, however, an RDFI that purchases branches 
or accounts from another RDFI may be precluded by 
the selling institution from placing the original (selling) 
RDFI's routing number in the NOCs Originating DFI 
Identification field. In this situation, the purchasing 
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RDFI may use its own routing number in the 
Originating DFI Identification field of the NOC to 
identify itself as having originated the Notification of 
Change entry. An RDFI that purchases branches or 
accounts should ensure that its software package allows 
it the ability to place its own routing number in the 
Originating DFI Identification field in the NOC. 

; • A valid Notification of Change Code must be used. 
The RDFI warrants that it is providing accurate 
information, and, to the extent the information consists 
of a change in a Receiver's deposit account number, 
that the Receiver has appropriately authorized the 
change, if such an authorization is required. The 
Originator can make the change without contacting the 
Receiver. 

Automated Notification of Change 

The RDFI (if it is not an ODFI) must be aware of the 
processing requirements of its ACH Operator and ACH 
Association before it originates Notifications of Change 
in automated format. In addition to the above 
requirements for all NOCs, the following guidelines apply 
to automated NOCs: 

• An addenda record must accompany the Entry Detail 
Record. The addenda record carries the Change Code 
and the corrected or changed information. 

• An Addenda Type Code of 98 must be used. 

• The Standard Entry Class Code COR must be used. 



All other requirements of Appendix Two and Appendix 
Six in XheNACHA Operating Rules must be followed. 

The RDFI that is unable to initiate Notifications of 
Change in an automated environment must contact its 
ACH Operator to determine what options are available for 
initiating non-automated NOCs. 



5. USE OF A THIRD PARTY TO ORIGINATE 
NOTIFICATIONS OF CHANGE 

If the RDFI is unable to automate NOCs, it may wish to 
use the services of a Third-Party Service Provider for the 
conversion of NOC source documents to the COR format 
prior to delivery to the ACH Operator. A Third-Party 
Service Provider may be a service bureau (usually the 
RDFI's Receiving Point), correspondent financial 
institution, or other organization. When using a Third- 
Party Service Provider for this purpose, responsibilities 
and liabilities, as well as processing deadlines, should be 
clearly defined. 



'6. RETURNED AND REFUSED NOTIFICATIONS 
OF CHANGE 

The RDFI should be aware that the Notification of 
Change it has originated may not be processed for certain 
reasons. Notifications of Change can be: 

Returned: by the ACH Operator - Once a Notification 
of Change has been entered into the ACH 
system, either from a non-automated or 
automated source, it may reject for specific 
reasons. In that case, the ACH Operator will 
send the entry back to the RDFI as a Return 
from the ACH Operator. It will carry a 
Return Reason Code indicating why it could 
not be processed. RDFIs should determine 
what procedures are used by its ACH 
Operator if a non-automated Notification of 
Change document cannot be entered into the 
ACH system. 



Refused: 



by the ODFI/Originator - In this case, the 
Notification of Change has been processed 
through the ACH system; however, the 
Originator or ODFI was not able to handle 
the NOC for a specific reason. The ODFI or 
Originator may use the Refused Notification 
of Change process to indicate why the NOC 
could not be handled. 



Refused Notification of Change Codes 

Refused Notification of Change codes designate the 
reason for refusal by the ODFI or Originator; They are 
listed below. 

C61 Misrouted Notification of Change 

C62 Incorrect Trace Number 

C63 Incorrect Company Identification Number 

C64 Incorrect Individual Identification Number 

C65 Incorrectly Formatted Corrected Data 

C66 Incorrect Discretionary Data 

€67 Routing Number Not From Original Entry 
Detail Record 



C68 DFI Account Number Not From Original Entry 
Detail Record 

C69 Incorrect Transaction Code 

The RDFI's ACH receiving software must be able to 
identify Refused Notifications of Change from the 
ODFI/Originator and rejected Notifications of Change 
that have been returned by the ACH Operator. Upon 
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receipt of an "unprocessed" NOG, the RDFI should 
determine why the NOG could not be processed, make the 
correction to the NOC, and reinitiate it into the ACH 
system. 

C. RESPONSIBILITIES OF ODFIs 

Notifications of Change that are received by the ODFI 
must be forwarded to the Originator for action. ODFIs 
are required to provide to the Originator, within two 
banking days of the settlement date of the NOG or 
Corrected NOG, the following minimum level of 
information relating to NOCs and Corrected NOCs: 

• Company Name; 

• Company Identification; 

• Company Entry Description; 

• Effective Entry Date; 

• DFI Account Number; 

• Individual Name/Receiving Company Name; 

• Individual Identification Number/Identification 
Number; 

• Change Code; 

• Original Entry Trace Number; 

• Original Receiving DFI Identification; and 

• Corrected Data. 

To ensure that changes requested by an RDFI via the 
NOC and corrected NOC process are successfully made 
by the Originator, it is critical that the ODFI provide the 
Originator with a detailed explanation of the type of 
information that will be provided to them via the NOC 
process. ODFIs that provide Originators with NOC 
information via a paper report should ensure that their 
Originators understand how to interpret the information 
provided by the ODFI. 

Although the NACHA Operating Rules do not require that 
the change code description be provided to the Originator 
as part of the descriptive information for each NOG or 
corrected NOG entry, ODFIs should provide Originators 
with detailed change code descriptive information to 
ensure proper handling of these entries by the Originator. 
ODFIs may choose to provide change code descriptive 
information by including it as part of me information 
provided by the ODFI to the Originator for each NOC or 
corrected NOG. Or, ODFIs may prefer to provide 
Originators with a list of change codes and their 
descriptions up front (e.g., provide a copy of the NACHA 
Operating Rules) for reference with all future NOCs and 
corrected NOCs. Alternatively, ODFIs and their 
Originators may agree that NOC information will be 
transmitted between them electronically in an effort to 
automate the NOC process. In such a scenario, the ODFI 
will need to ensure that the Originator is provided with 
change code descriptions. 

However, there may be instances when the ODFI cannot 
forward the entry. This usually occurs when information 
from the original entry was not included on the NOC and 



the ODFI is unable to identify the entry or the Originator. 
The ODFI should be aware that there may not be a match 
between the Originating DFI Identification field in the 
Company/Batch Header Record of the NOC and the 
Receiving DFI Identification field of the original entry. 
However, the RDFI's routing number from the original 
entry can be located in the Original Receiving DFI 
Identification field in the addenda record of the NOG. 
The ODFI may use the Refused Notification of Change 
process to inform the RDFI that the NOC was not 
processed. A Refused NOC must be initiated within 15 
days of the receipt of the NOC and must be in automated 
format. Refused NOC Codes that identify these specific 
scenarios may be: 

€61 Misrouted Notification of Change - the NOG was 

sent to the wrong ODFI. 

€63 Incorrect Company Identification Number - the 
ODFI cannot identify the Originating Company. 

The ODFI may also choose to edit the NOC for other 
information and refuse it for its Originating Company. 
Other Codes for which an NOC can be refused by the 
ODFIare: 

€62 Incorrect Trace Number - the trace number found 
on the NOG is different from the trace number of the 
original entry. If the trace number cannot be matched to 
the original entry, the Originator may be unable to make 
the requested change. 

€64 Incorrect Individual Identification Number - the 

Originator may use this field to identify the Receiver. If 
the information in this field is incorrect, the Originator 
may not be able to make the requested change . 

€65 Incorrectly Formatted Corrected Data - the 

Originator may identify the entry but cannot read the 
addenda information which should contain the correct 
information. 

€66 Incorrect Discretionary Data - the Originator may 
not be able to identify the application from which the 
entry was originated and therefore cannot make the 
requested change. 

€67 Routing Number Not From Original Entry Detail 
R ecord - based on the information included on the NOC, 
the Originator cannot determine where the original entry 
was sent, and therefore is unable to make the requested 
change. 

€68 DFI Account Number Not From Original Entry 
Detail Record ' - based on the information contained in the 
NOC, the Originator cannot determine the account 
number at the DFI and is therefore unable to process the 
change. 




OG7I 



SECTION III -FUNCTIONAL RESPONSIBILITIES 
CHAPTER III -RETURNS 



2005 OPERATING GUIDELINES 




€69 Incorrect Transaction Code - the transaction code 
contained in the NOC is different from the transaction 
code on the original entry; the Originator may be unable 
to identify the original transaction and make the requested 
change. 

General Guidelines for Receiving Notifications of Change 
at the ODFI: 

• Ensure that NOCs are recognized by ACH receiving 
software. 

• Establish procedures to forward NOC data to 
Originators. 

•■ Provide guidance to Originators that must interpret 
NOCs and make changes to ACH entries. 

• Establish procedures to refuse an NOC within 15 days 
and identify reason for refusal. 

D. RESPONSIBILITIES OF ORIGINATORS 

Originators are required to respond to Notifications of 
Change by investigating incorrect data and making 
corrections within six banking days of receipt of the NOC 
information or prior to initiating another entry to the 
Receiver's account, whichever is later. It is not necessary 
or recommended to wait six banking days if the change 
can be made earlier. Originators should always make the 
change prior to initiating the next entry, if possible. 
Originators should be thoroughly familiar with the NOC 
Change Codes and their meanings. Originators should 
work with their ODFIs to agree upon the method by which 
NOC information will be provided by the ODFI (e.g., via 
electronic media, paper format, etc.) and should ensure 
that they have a thorough understanding of how to 
interpret NOC provided by their financial institutions. 
NOC Change Codes generally fall into two categories: 

• Codes that indicate an error in the account information 
- entries carrying these codes indicate that the RDFI did 
receive the entry but the account information or 
information regarding the Receiver was incorrect. 
Changes must be made so that the RDFI can handle the 
entry appropriately. 

• Codes that indicate an error in the routing of the entry - 
entries carrying these codes indicate that the entry 
needs a change in the routing information. Failure to 
change the routing information could cause subsequent 
entries to be delayed or returned. An Originator should 
not assume, however, that a change to a Routing 
Number affects all ACH transactions going to that 
Routing Number. For example, if a financial institution 
buys some branches of a failed institution, it might 
initiate NOCs only for those specific accounts they 
have now taken over. The original Routing Number 
may be valid for other accounts. 



Originators should monitor the Notifications of Change 
that are received to see if enrollment procedures should be 
modified. 

When identifying the original entry referenced in an NOC, 
Originators should be aware that, when an account or 
branch has been sold to another RDFI, the routing number 
in the Receiving DFI Identification field of the original 
entry may not match the routing number in the Originating 
DFI Identification field of the NOC. However, the RDFI's 
routing number from the original entry can be located in 
the Original Receiving DFI Identification field in the 
addenda record of the NOC. 

An Originator should be familiar with the Refused 
Notification of Change process for its ODFI to notify the 
RDFI that it cannot process the Notification of Change. 
Procedures must be established between the Originator 
and the ODFI for the origination of Refused NOCs, which 
must be in automated format. 



SECTION III 

FUNCTIONAL RESPONSIBILITIES 

CHAPTERIII 
RETURNS, DISHONORED 
RETURNS, CONTESTED 
DISHONORED RETURNS 

A, INTRODUCTION 

The ACH process includes the ability to return entries for 
specific reasons. The process allows various participants 
in the system to exercise their respective rights not to 
accept an entry and to return it to the Originator through 
the ACH Network. When the return has been initiated by 
the RDFI and subsequently flows through the ACH 
system to the ODFI, the ODFI has the right to dishonor 
the return under specific circumstances. The RDFI may 
react to that dishonor by accepting the dishonor, 
contesting the dishonor, or by correcting the return. The 
procedure is as follows: 

1. The RDFI receives an ACH entry and returns it to 
the ODFI. 

2. The ODFI evaluates the return and generates a 
dishonored return. The return is dishonored either as 
untimely or as containing incorrect information. 

3. The RDFI either accepts the dishonored return, 
contests the dishonored return (if the return was 
dishonored as untimely), or corrects the return. 
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The sequence above can take place only once; there is no 
further recourse available to the parties within the ACH 
Network. Any disagreement beyond this point must be 
handled outside the ACH process. 

With these rights are specific responsibilities. The rights 
and responsibilities for all participants in the return, 
dishonored return, and contested dishonored return 
process are outlined in this chapter by participant. 

B. RESPONSIBILITIES OF ORIGINATORS 

1. RETUIWSyy'-^ 

Preparing to Receive Returns 

Entries initiated into the ACH system, either 
prenotification entries or live dollar entries, may be 
returned for specific reasons. These reasons are defined 
by Return Reason Codes. Some codes are used solely by 
the ACH Operator while others are used when a return is 
originated by an RDFI. It is essential that the Originator 
work closely with its ODFI to establish procedures for 
handling returns. Addenda records are not returned. For 
example, the Originator initiates a CTX entry that carries 
addenda records. If the CTX entry is returned, it will be 
returned without the original addenda records. 

Returns for Insufficient Funds 

In a debit application, entries can be returned by the RDFI 
if there are not funds in the Receiver's account to cover 
the debit entry, i.e., insufficient funds (NSF) or if there are 
uncollected funds so the entry cannot be honored. The 
specific Return Reason Codes used by the RDFI are R01 
for NSF and R09 for uncollected funds. These codes are 
unique in that entries returned with the codes can be re- 
originated through the ACH Network. The Originator 
will want to make arrangements with its ODFI for the 
handling of debit entries returned for NSF or uncollected 
funds. Originators should note that the NACHA 
Operating Rules impose a limit on the number of times 
that an entry returned for insufficient or uncollected funds 
may be reinitiated. Detailed information on the 
reinitiation of returned entries can be found later in this 
chapter. 

Returns for Revocation of Authorization 

In a debit application, entries may be returned by the 
RDFI for R07 (Authorization Revoked by Customer) if 
the Receiver has provided the RDFI with a written 
statement under penalty of perjury in which the Receiver 
states that the authorization for the debit entry was 
revoked directly with the Originator under the terms and 
conditions set forth in the authorization agreement. (Note: 
For additional information on written statements under 
penalty of perjury, refer to the RDFIs chapter in Section 
II of these Guidelines.) The Originator may request that 
its ODFI obtain a copy of the written statement under 



penalty of perjury from the RDFI, when appropriate/The 
ODFPs written request for such a copy must be received 
by the RDFI within one year of the date on which the 
adjustment entry was initiated by the RDFI. (A sample 
written statement under penalty of perjury may be found 
in the RDFIs chapter in Section II of these Guidelines,) 
The RDFI must comply with the ODFFs request for a 
copy of the written statement under penalty of perjury 
within sixty days of receiving the ODFI's written request 
for such a document. Originators may not reinitiate 
entries returned for authorization revoked and should be 
prepared to contact the Receiver regarding those entries. 
(Note: POP entries, TEL entries, and Single Entry WEB 
entries may not be returned using Return Reason Code 
R07 -Authorization Revoked.) 

Returns for Unauthorized/ Improper Consumer Debits 

Unauthorized Consumer Debit Entries 

Originators can expect the return of entries that were not 
properly authorized. An unauthorized debit entry is an 
entry in which: 

• the written authorization requirements have not been 
followed; 

• a transaction was initiated in an amount greater than 
that authorized by the Receiver; 

V a transaction was initiated for settlement earlier than 
authorized by the Receiver; or 

• with respect to ARC entries, (1) notice was not 
provided to the Receiver by the Originator in 
accordance with the requirements of the NACHA 
Operating Rules, (2) the entry was transmitted to an 
account of a Receiver who opted out of ARC check 
conversion activity, or (3) the amount of the ARC entry 
was not accurately obtained from the source document. 

Consumer debit entries returned by the RDFI as 
unauthorized will bear Return Reason Code RIO 
(Customer Advises Not Authorized, Notice Not Provided, 
Improper Source Document, or Amount of Entry Not 
Accurately Obtained from Source Document) and must be 
returned by the RDFI in such time and manner that the 
return is made available to the ODFI no later than the 
opening of business on the banking day following the 
sixtieth calendar day following the Settlement Date of the 
original entry; This return deadline also applies to debit 
entries for which the consumer Receiver had previously 
revoked his authorization for the transaction (Return 
Reason Code R07 -Authorization Revoked). 

At times, Originators may erroneously transmit ACH 
entries that are formatted using an incorrect SEC Code. 
This is in violation of the NACHA Operating Rules. 
Because the Rules require the RDFI to rely on the ODFI's 
warranty that the SEC Code included in the entry is 
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proper, the RDFI is obligated to use the return rules and 
time frames associated with that particular SEC Code. 
Currently, an unauthorized debit to a consumer account 
where that entry incorrectly bears a corporate SEC Code 
must be returned in accordance with the return rules and 
time frames governing corporate transactions (that is, 
using Return Reason Code R29 within two banking days 
of the Settlement Date of the original entry). In such 
cases, the RDFI is typically precluded from automatically 
returning such an unauthorized debit because the return 
time frame for corporate entries will have lapsed before 
the consumer can receive his statement and notify his 
RDFI about the unauthorized debit to his account. 
Instead, the RDFI would be required to request 
permission from the ODFI to return the entry as a 
permissible return. 

Effective March 18, 2005, a new Return Reason Code 
R05 (Unauthorized Debit to Consumer Account Using 
Corporate SEC Code) will become available to RDFIs for 
the return of unauthorized debits transmitted to consumer 
accounts when those debit entries incorrectly bear a 
corporate SEC Code (i.e., CCD, CTX, or CBR). With the 
addition of this rule, the RDFI will be permitted to return 
all unauthorized debits to consumer accounts, regardless 
of SEC Code, within sixty days of the Settlement Date of 
the original entry, provided the RDFI has obtained a 
written statement under penalty of perjury from the 
consumer. 

Ineligible/Improper Consumer Debit Entries 

Originators may also expect the return of entries that were 
ineligible for ACH origination or that were originated 
improperly. An ineligible or improper debit entry is an 
entry for which: 

* Ineligible RCK Entries: 

.'■—.'■ the item to which the entry relates is ineligible to 
be initiated as an RCK entry (Return Reason Code 

- the required notice stating the terms of the re- 
presented check entry policy was not provided by 
the Originator in accordance with the requirements 
of the NACHA Operating Rules (Return Reason 
CodeR51); 

- all signatures on the item to which the RCK entry 
relates are not authentic or authorized, or the item 
has been altered (Return Reason Code R51); 

.— the amount of the RCK entry was not accurately 
obtained from the item (Return Reason Code 
R51);or 

- both the RCK entry and the item to which the 
RCK entry relates have been presented for 
payment (Return Reason Code R53). 



Improper ARC Entries: 



the source document used for the debit entry is 
improper (Return Reason Code RIO): 

- checks drawn on corporate or business 
accounts; 

- third-party checks; 

- demand drafts/third-party drafts that do not 
contain the signature of the Receiver; 

- credit card checks; 

- obligations of a financial institution (travelers 
checks, cashier's checks, official checks, money 
orders, etc.) 

- checks drawn on the U.S. Treasury, a Federal 
Reserve Bank, or a Federal Home Loan Bank; 

■ - checks drawn on a state or local government; 

- checks payable in a medium other than United 
States currency. 

the source document was presented for payment 
(Return Reason Code R37). 



Ineligible POP Entries: 

- the source document used for the debit entry is 
improper (Return Reason Code RIO): 



- checks drawn on corporate or business accounts; 

- third-party checks; 

- credit card checks; 

- obligations of a financial institution (travelers 
checks, cashier's checks, official checks, money 
orders, etc.) 

- checks drawn on the U.S. Treasury, a Federal 
Reserve Bank, or a Federal Home Loan Bank; 

- checks drawn on a state or local government; 

- checks payable in a medium other than United 
States currency; 

- previously voided checks/sharedrafts used for 
prior POP entries. 



- the source document was presented for payment 
(Return Reason Code R37). 

Originators receiving returns for Return Reason Codes 
R05 (effective March 18, 2005), RIO, R37, R51, andR53 
should be aware that the RDFI is warranting that it has 
obtained a written statement under penalty of perjury from 
the consumer in which the consumer states that the debit 
entry being returned was not authorized or is 
ineligible/improper. The procedures for obtaining a copy 
of the written statement under penalty of perjury are the 
same as previously discussed in the section on Revocation 
of Authorization. Originators may not reinitiate entries 
returned using these Return Reason Codes and should be 
prepared to contact the Receiver regarding those entries. 
(Note: For additional information on written statements 
under penalty of perjury, refer to the chapter on RDFIs in 
Section II of these Guidelines.) 
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Returns for Death of Beneficiary, Representative Payee, 
or Account Holder 

Entries may be returned by the RDFI if the RDFI has 
become aware of the death of the beneficiary, 
representative payee, or account holder. Originators 
should be aware of the specific differences between 
Return Reason Codes R14 and Rl 5 to ensure that returns 
bearing these codes are handled appropriately by the 
Originator. 

Originators should be aware that returns bearing Return 
Reason Code R14 (Representative Payee Deceased or 
Unable to Continue in that Capacity) are transmitted when 
a representative payee has been assigned to receive 
benefit payments on behalf of the entitled individual. A 
representative payee is a person or institution authorized 
to accept entries on behalf of one or more other persons, 
such as legally incapacitated adults or minor children. 
Returns bearing Return Reason Code R14 indicate that the 
representative payee, and not the beneficiary of the 
payments, has died. The beneficiary is not deceased and 
is still entitled to the benefit payments. This Return 
Reason Code should not be used unless a representative 
payee exists. 

Returns bearing Return Reason Code Rl 5 (Beneficiary or 
Account Holder [Other Than a Representative Payee] 
Deceased) will indicate either (1) in the case of benefit 
payments where no representative payee has been 
assigned, the actual beneficiary is deceased, or (2) in the 
case where the payment is not a benefit payment (i.e., 
insurance premium debit), the owner of the account has 
died and the payment is being returned by the RDFI. 

General Guidelines 

In addition to being knowledgeable about specific codes, 
the Originator should: 

• Establish schedules with its ODFI for the receipt of 
return data. 

v Establish procedures for handling returns for NSF or 
uncollected funds. 

. •.'■ Establish procedures with the Receiver for an 
appropriate course of action should an entry be 
returned: 

credits - an alternate form of payment maybe 
appropriate until the reason for return is 
researched and resolved. 

debits - an alternate form of collection may be 
appropriate if a debit entry is returned, 
depending upon the reason for return. 

• Establish a deadline for accepting debit returns after 
which debit returns will be dishonored. A return can be 



dishonored as untimely only if the return was not 
initiated within the appropriate time frames and only if 
the ODFI or Originator has suffered a loss. 

2. REINITIATION OF RETURNED ENTRIES 

The NA CHA Operating Rules preclude an Originator from 
reinitiating a returned ACH entry unless (1) the entry has 
been returned for insufficient or uncollected funds; (2) the 
entry has been returned for stopped payment and 
reinitiation has been authorized by the Receiver, or (3) the 
ODFI has taken corrective action to remedy the reason for 
the return. The NACHA Operating Rules impose a limit 
on the number of times that an entry returned for 
insufficient or uncollected funds may be reinitiated by an 
Originator or its ODFI, allowing such entries to be 
reinitiated no more than two times following the return of 
the original entry. This limit applies to all Standard Entry 
Class Codes except RCK, which has its own distinct limit 
on the number of presentments. 

3. DISHONORED RETURNS 

The Originator may have its ODFI dishonor a return for 
specific reasons, which fall into two categories as follows: 

• The entry has been returned later than the deadline 
established for accepting returns, and either the 
Originator or the ODFI has suffered a loss. 

•.'■ The return entry contains incorrect information. 

The Originator should be aware, however, that the RDFI 
may contest the dishonor that has been issued for an 
untimely return, or it may initiate a corrected return. If an 
Originator fails to utilize the Dishonored Return process, 
such failure does not preclude its right to seek recovery 
against an RDFI outside of the ACH return process for a 
late return. 




C. RESPONSIBILITIES OF QDFIs 



1. RETURNS 



Returns are sent by the ACH Operator to the ODFFs 
Receiving Point in automated format. They are included 
in regular ACH file s . Therefore, the ODFFs receiving 
software must be able to recognize returns and sort them 
appropriately for action by the ODFI. 

Returns can be initiated from one of two sources: 

• ACH Operator - entries that cannot be processed 
through the ACH system will be returned to the ODFI 
and will carry Return Reason Codes used only by ACH 
Operators. A complete list of Return Reason Codes 
used by the ACH Operator can be found in the 
RESPONSIBILITIES OF ACH OPERATOR section of 
this chapter. 
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These entries were never received at the RDFI. The 
Originator should be notified immediately that entries 
were returned by the ACH Operator so that they can 
initiate a corrected entry or utilize an alternate method 
of payment. 

8 RDFI - entries that are rejected at the RDFI will be 
returned for specific reasons. A complete list of Return 
Reason Codes to be used by the RDFI can be found in 
the RESPONSIBILITIES OF RDFIs section of this 
chapter. 

Once returns are identified at the ODFFs Receiving Point, 
theODFImay: 




• Forward the Return to the Originator for action. 

• Reinitiate an entry for the Originator if it has been 
returned for R01 (Insufficient Funds) or R09 
(Uncollected Funds). (Note: The number of times that 
an entry returned for R01 or R09 can be reinitiated 
must not exceed the limits established by the NACHA 
Operating Rules.) 

• ' Dishonor the Return. 

All ODFIs must be aware of specific processing windows 
offered by ACH Operators for the processing of returns. 
It is likely that ODFIs will have returns available from 
ACH Operators toward the end of the business day. 
ODFIs should make sure that the files containing these 
returns are picked up prior to the close of business for 
proper posting and handling. 

When an ODFI receives a return bearing Return Reason 
Code R05 (effective March 18, 2005), R07, RIO, R37, 
R38, R51, or R53, the RDFI has warranted that it has 
obtained a written statement under penalty of perjury from 
the Receiver stating that the Receiver did not authorize the 
transaction or that the entry was improperly originated. 
The ODFI has up to one year from me return of the 
original entry to request, in writing, that the RDFI provide 
a copy of the written statement under penalty of perjury. 
ODFIs should establish procedures to accept requests 
from their Originators for copies of written statements 
under penalty of perjury and for making those requests to 
RDFIs, (Note: For additional information on written 
statements under penalty of perjury, refer to the chapter 
on RDFIs in Section II of these Guidelines.) 

2. REINITIATION OF RETURNED ENTRIES 

The NA CHA Operating Rules preclude an Originator from 
reinitiating a returned ACH entry unless ( 1 ) the entry has 
been returned for insufficient or uncollected funds; (2) the 
entry has been returned for stopped payment and 
reinitiation has been authorized by the Receiver, or (3) the 
ODFI has taken corrective action to remedy the reason for 
the return. The NACHA Operating Rules impose a limit 
on the number of times that an entry returned for 



insufficient or uncollected funds may be reinitiated by an 
Originator or its ODFI, allowing such entries to be 
reinitiated no more than two times following the return of 
the original entry. This limit applies to all Standard Entry 
Class Codes except RCK, which has its own distinct limit 
on the number of presentments. 



3. DISHONORED RETURNS 



A return can be sent back (dishonored) to the RDFI if the 
return was untimely or if the return contained incorrect 
information. A dishonored return must be sent within five 
banking days of the Settlement Date of the return. 

If an Originator fails to utilize the Dishonored Return 
process, such failure does not preclude its right to seek 
recovery against an RDFI outside of the ACH return 
process for a late return. 

How to Dishonor an Untimely Return 

The issue of untimely returns usually occurs in debit 
applications. An ODFI will probably accept a returned 
credit entry even if it is received late; however in a debit 
application where money is owed to the Originator, the 
late return of an entry could make it difficult for the 
Originator to collect the funds that are owed. When a 
return is originated by the RDFI in an untimely manner, 
the ODFI has the right to send that entry back to the RDFI 
if the ODFI or the Originator has suffered a loss . The 
rules require that each return entry be received by the 
RDFI's ACH Operator by its deposit deadline for the 
return entry to be made available to the ODFI no later 
than the opening of business on the second banking day 
following the Settlement Date of the original entry. The 
term "second banking day" refers to the second banking 
day of the RDFI's ACH Operator. The term "Settlement 
Date of the original entry" refers to the Settlement Date of 
the original entry that is being returned. 

The ODFI should observe the following steps regarding 
untimely returns: 

• Establish a deadline with the Originator after which it 
no longer will accept returns. 

• Determine whether or not a loss has been suffered by 
either the Originator or the ODFI. If the Originator can 
collect the monies owed outside of the ACH system, 
then it should not dishonor the return. 

• Originate the Dishonored Return in automated format 
using the Dishonored Return Code R68. 

• Establish procedures for handling Dishonored Returns 
that may be contested or corrected by the RDFI. 
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How to Dishonor a Return that Contains Incorrect 
Information 

It is possible that a Return can contain incorrect 
information that will inhibit the Originator's or ODFI's 
ability to handle the return. When that occurs, the ODFI 
may dishonor a return for specific reasons. These reasons 
are categorized by the following codes: 

R61 Misrouted Return - the RDFI has sent the Return 
back to the wrong ODFI. This happens when the wrong 
Routing Number is inserted in the Entry Detail Record of 
the Return. The ODFI is unable to accept this entry. 

R62 Incorrect Trace Number- the RDFI has not sent the 
trace number of the original entry back with the return of 
that entry; therefore, the ODFI is not able to identify the 
original entry. 



R63 Incorrect Dollar Amount -the RDFI is returning an 
entry for an amount that differs from the amount of the 
original entry. This is prohibited by NA CHA Operating 
Rules. 

R64 Incorrect Individual Identification - the RDFI has 
not sent back the Individual Identification number that 
was on the original entry; therefore, the ODFI is not able 
to identify me original entry. 

R65 Incorrect Transaction Code - the Transaction Code 
contained in the return entry is different from the 
Transaction Code in the original entry. The ODFI may 
therefore be unable to identify the original entry and 
process the return. 

R66 Incorrect Company Identification - the RDFI has 
sent back a Company Identification that was not contained 
on the original entry; therefore, the ODFI could not 
identify the Originator of the entry. 

R67 Duplicate Return - more than one return for the 
same entry has been received at the ODFI. 

R68 Untimely Return - the return has not been sent 
within the time frame established by the NACHA 
Operating Rules and may not be accepted by the ODFI. 

R69 Multiple Errors - two or more of the following 
fields in the return are incorrect -Original Entry Trace 
Number, Amount, Individual Identification Number, 
Company Identification and/or Transaction Code; the 
ODFI is therefore unable to identify the original entry and 
process the return. 

R70 Permissible Return Entry Not Accepted - the ODFI 
has received a corporate return entry (CCD or CTX) 
identified by the RDFI as being returned with the 
permission of the ODFI, but the ODFI has not agreed to 
accept the entry. This code is only to be used to dishonor 



a return when an R31 return reason code has been 
received. 

The ODFI must coordinate procedures with its 
Originators for identifying returned entries and initiating 
a dishonored return. 

Receiving Contested and Corrected Dishonored Returns 

The ODFI can expect to receive notice from the RDFI that 
it is contesting or correcting a Dishonored Return. This 
notice is a Contested Dishonored Return. The RDFI 
contests a Dishonored Return when the ODFI has 
dishonored the return as untimely but the RDFI claims 
that it did return the entry in a timely manner. 

Untimely Entries 

When an ODFI dishonors a return as untimely, the RDFI 
has the right to contest the dishonor if the RDFI met the 
required time frame for the return. The RDFI must do so 
within two banking days of the Settlement Date of the 
dishonored return claim. The RDFI's claim that it did, in 
fact, return the entry in a timely manner is the final course 
of action for that entry for either party within the ACH 
process . Once an ODFI receives a Contested Dishonored 
Return for an entry that it claimed was returned late, that 
ODFI must look to procedures outside of the ACH system 
to settle any further dispute with the RDFI. The process 
can be outlined as follows: 

Step 1 The Originator sends an entry through the ACH 
Network to a Receiver. If the return time frame 
was not met, the RDFI may: 

• recover funds from its depositor. 

• suffer the loss. 

Step 2 The RDFI returns the entry. 

Step 3 The ODFI or Originator suffers a loss because the 
return is untimely and dishonors the return, 
sending it back to the RDFI. 

Step 4 The RDFI researches the original and return entry 
and determines whether or not it originated the 
return in a timely manner. The RDFI warrants that 
it has proof that the original return entry did meet 
the established time frames and that it can verify 
that information. 

Step 5 The RDFI sends a Contested Dishonored Return 
entry to the ODFI. 

Step 6 The ODFI looks to procedures established by 
agreement with its Originator for the appropriate 
manner in which to handle the entry: 

':■.•■ forward the entry to the Originator. 
■ .• pursue the issue with the RDFI. 
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■ • ■ pursue the issue through the NACHA arbitration 

process. 
■• suffer the loss. 

Corrected Entries 

When an ODFI dishonors a return because it contains 
incorrect information, the RDFI has the right to transmit 
a corrected return within two banking days of the 
Settlement Date of the dishonored return entry. The RDFI 
uses the contested dishonored return process to make the 
correction and may initiate the entry in automated or 
paper format. The ODFI will always receive the 
contested (corrected) dishonor in automated format as 
non-automated data is converted by the ACH Operator. 

D. RESPONSIBILITIES OF ACH OPERATORS 

The role of the ACH Operator is separated into two 
categories regarding returns, dishonored returns, and 
contested dishonored returns: 

° As a participant in the flow of an ACH entry, an ACH 
Operator may itself create returns. 

■ •■ As a processor, the ACH Operator handles returns, 
dishonored returns, and contested dishonored returns 
for the other participants. 

Below is a description of the functional responsibilities of 
the ACH Operator as they relate to these two separate 
roles. 

1. RETURNS INITIATED BY ACH OPERATOR 

The ACH Operator must edit all entries that enter the 
ACH system and return those that it cannot process. 
Therefore, both the ODFI and the RDFI should be able to 
identify entries returned by the ACH Operator at their 
Receiving Points . 

The reasons for which an entry can be returned by the 
ACH Operator are: 

Rl 3 Receiving DFI Not Qualified to Participate. 

Rl 8 Improper Effective Entry Date. 

RI9 Amount Field Error. 

R25 Addenda Error. 

R26 Mandatory Field Error. 

R27 Trace Number Error. 

R28 Routing Number Check Digit Error. 

R30 RDFI Not Participant in Check Truncation 

Program. 
R32 RDFI Non-Settlement 
R34 Limited Participation DFI 
R35 Return of Improper Debit Entry. 
R3 6 Return of Improper Credit Entry. 



Full descriptions of the above ACH Operator Return 
Reason Codes can be found in Appendix Three of the 
NACHA Operating Rules. 

Any entry that bears a Return Reason Code used only by 
an ACH Operator was not successfully processed through 
the ACH Network. Therefore, the RDFI and Receiver 
identified on the original entry never actually received the 
entry. All ODFIs and RDFIs must recognize the 
significance of ACH Operator Return Codes. The entries 
bearing these Codes must be researched and possibly 
reinitiated; 

It is also important that the ODFI or RDFI that receives a 
return initiated by the ACH Operator avoids looping. An 
entry can get caught in a loop, for example, when a return 
entry is returned by the ACH Operator and the financial 
institution to which it was sent does not recognize it as 
being returned by the ACH Operator. This could cause 
the entry to be caught in a loop (returned repeatedly by 
both the financial institution and the ACH Operator). 

2. PROCESSING RETURNS, DISHONORED 

RETURNS, AND CONTESTED DISHONORED 
RETURNS INITIATED BY OTHER ACH 
PARTICIPANTS 

Automated returns, dishonored returns, and contested 
dishonored returns are edited by the ACH Operator as are 
other entries originated into the ACH system. For more 
information on File, Batch, and Entry Level rejection, 
refer to the ACH Operators chapter in Section II of these 
Guidelines. 



Automated Returns, Dishonored Returns, and 
Contested Dishonored Returns 

ACH Operators edit and process automated returns, 
dishonored returns, and contested dishonored returns in 
the same manner in which they process regular entries. 

Each ACH Operator will establish its own products and 
services for accepting and/or rejecting non-automated 
returns and contested dishonored returns from DFIs. 

E, RESPONSIBILITIES OF RDFIs 

1. RETURNS 
Reasons for Return 



RDFIs must return entries that are not posted to Receivers' 
accounts. Prenotification entries should also be returned 
when the RDFI wishes to advise the Originator not to 
initiate the subsequent live entry. Entries must be 
returned for valid reasons, as follows: 

R01 Insufficient Funds. The available and/or cash 
reserve balance is not sufficient to cover the dollar value 
of the debit entry. 
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R02 Account Closed. A previously active account has 
been closed by action of the customer or the RDFI. 

R03 No Account/Unable to Locate Account. The 

account number structure is valid and passes the check 
digit validation, but the account number does not 
correspond to the individual identified in the entry, or the 
account number designated is not an open account. This 
Return Reason Code may not be used to return an ARC or 
POP entry solely because it lacks an Individual Name. 



R04 Invalid Account Number. The account number 
structure is not valid, the entry may fail the check digit 
validation, or it may contain an incorrect number of digits. 

R05 Reserved. (NOTE: Effective March 18, 2005, 
Return Reason Code R05 will be reactivated to 
accommodate the return of unauthorized debit entries to 
consumer accounts when those debits were transmitted 
using a corporate Standard Entry Class Code. As of 
March 1 8, 2005, the title of Return Reason Code R05 will 
read "Unauthorized Debit to Consumer Account Using 
Corporate SEC Code (adjustment entries)." The 
definition of this revised return reason code will read as 
follows: "A CCD, CTX, or CBR debit entry was 
transmitted to a Consumer Account of the Receiver and 
was not authorized by the Receiver. The Receiver may 
request immediate credit from the RDFI for an 
unauthorized debit. The request must be made in writing 
within fifteen (15) days after the RDFI sends or makes 
available to the Receiver information pertaining to that 
debit entry/ The Receiver must also provide the RDFI 
with a written statement under penalty of perjury, pursuant 
to subsection 8.6.5 (Receiver's Written Statement Under 
Penalty of Perjury), that the debit entry was not authorized 
by the Receiver. For purposes of this code and related 
Operating Rules provisions, a debit entry was not 
authorized by a Receiver if (1) the authorization 
requirements of Article Two, subsection 2.1.2 (Receiver 
Authorization and Agreement) have not been met; (2) the 
debit entry was initiated in an amount greater than that 
authorized by the Receiver; or (3) the debit entry was 
initiated for settlement earlier than authorized by the 
Receiver. An unauthorized debit entry does not include 
a debit entry initiated with fraudulent intent by the 
Receiver or any person acting in concert with the 
Receiver. An RDFI using this return reason code must 
transmit the return entry by its ACH Operator's deposit 
deadline for the return entry to be made available to the 
ODFI no later than the opening of business on the banking 
day following the sixtieth calendar day following the 
Settlement Date of the original entry.") 

R06 Returned per ODFI Request. The ODFI has 

requested that the RDFI return the ACH entry. If the 
RDFI agrees to return the entry, the ODFI must indemnify 
the RDFI according to Article Six of the NACHA 
Operating Rules: 



R07 Authorization Revoked by Customer (adjustment 
entries) 

The RDFFs customer (the Receiver) has revoked the 
authorization previously provided to the Originator for 
this particular transaction. The Receiver may request 
immediate credit from the RDFI for an unauthorized 
debit. The request must be made in writing within fifteen 
( 1 5) days after the RDFI sends or makes available to the 
Receiver information pertaining to that debit entry. The 
Receiver must also provide the RDFI with a written 
statement under penalty of perjury stating that the 
authorization for the debit entry was revoked by the 
Receiver. The RDFI must return the rescinded transaction 
to its ACH Operator by its deposit deadline for the 
adjustment entry to be made available to the ODFI no 
later than the opening of business on the banking day 
following the sixtieth calendar day following the 
Settlement Date of the original entry. This code and 
related Operating Rule provisions apply to Consumer 
entries only. ( Note : This Return Reason Code may not be 
used for POP entries, Single-Entry WEB entries, or TEL 
entries.) 

R08 Payment Stopped 

The Receiver of a debit transaction has the right to stop 
payment on any specific ACH debit. A stop payment 
request should be handled in accordance with the 
provisions of Article Eight (Recall, Stop Payment, 
Recredit, and Adjustment) of the NACHA Operating 
Rules: The RDFI should verify the Receiver's intent when 
a request for stop payment is made to ensure this is not 
intended to be a revocation of authorization (R07) . A 
stop payment order shall remain in effect until the earliest 
of the following occurs: a lapse of six months from the 
date of the stop payment order, payment of the debit entry 
has been stopped, or the Receiver withdraws the stop 
payment order. 

R09 Uncollected Funds. Sufficient book or ledger 
balance exists to satisfy the dollar value of the transaction, 
but the dollar value of transactions in process of collection 
(e.g., uncollected checks) brings the available and/or cash 
reserve balance below the dollar value of the debit entry. 

RIO Customer Advises Not Authorized, Notice Not 
Provided, Improper Source Document, or Amount of 
Entry Not Accurately Obtained from Source Document 
(adjustment entries) 

9 For entries to Consumer Accounts that are not ARC 
entries, POP entries, or RCK entries, the RDFI has 
been notified by its customer, the Receiver, that the 
Originator of a given transaction has not been 
authorized to debit his account. The Receiver may 
request immediate credit from the RDFI for an 
unauthorized debit. The request must be made in 
writing within fifteen (15) days after the RDFI sends or 
makes available to the Receiver information pertaining 
to that debit entry. The Receiver must also provide the 
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RDFI with a written statement under penalty of perjury, 
pursuant to subsection 8.6.5 (Receiver's Written 
Statement Under Penalty of Perjury), that the debit 
entry was not authorized by the Receiver. For purposes 
of this code and related Operating Rules provisions, a 
debit entry was not authorized by the Receiver if (1) the 
authorization requirements of Article Two, subsection 
2.1.2 (Receiver Authorization and Agreement) have not 
been met; (2) the debit entry was initiated in an amount 
greater than that authorized by the Receiver; or (3) the 
debit entry was initiated for settlement earlier than 
authorized by the Receiver. An unauthorized debit 
entry does not include a debit entry initiated with 
fraudulent intent by the Receiver or any person acting 
in concert with the Receiver. The RDFI must return the 
rescinded transaction to its ACH Operator by its 
deposit deadline for the adjustment entry to be made 
available to the ODFI no later than the opening of 
business on the banking day following the sixtieth 
calendar day following the Settlement Date of the 
original entry. This code and related Operating Rule 
provisions apply to Consumer entries only. 



OR 



•.'■ For ARC entries, the RDFI has been notified by its 
customer, the Receiver, that (1) the required notice was 
not provided by the Originator in accordance with 
Article Three, subsection 3 .7. 1 (Notice Obligation), (2) 
the source document used for the debit entry is 
improper pursuant to subsection 3.7.2 (Source 
Documents), or (3) the amount of the ARC entry was 
not accurately obtained from me source document. The 
Receiver may request immediate credit from the RDFI 
for an ARC entry for the reasons described above. The 
request must be made in writing within fifteen (15) days 
after the RDFI sends or makes available to the Receiver 
information relating to that debit entry. The Receiver 
must also provide the RDFI with a written statement 
under penalty of perjury, pursuant to subsection 8.6.5.1 
(Receiver's Written Statement Under Penalty of Perjury 
for ARC Entries), that ( 1 ) the required notice was not 
provided, (2) the source document used for the debit 
entry is improper, or (3) the amount of the ARC entry 
was not accurately obtained from the source document. 
An RDFI using this Return Reason Code must transmit 
the return entry by its ACH Operator's deposit deadline 
for me return entry to be made available to the ODFI no 
later than the opening of business on the banking day 
following the sixtieth calendar day following the 
Settlement Date of the ARC entry. 



OR 



For POP entries, the RDFI has been notified by its 
customer, the Receiver, that (1) the Originator of a 
given transaction has not been authorized to debit his 
account, or (2) the source document for the debit entry 
is improper pursuant to subsection 3.8.1 (Source 
Documents). The Receiver may request immediate 



credit from the RDFI for a POP entry for the reasons 
described above. The request must be made in writing 
within fifteen (15) days after the RDFI sends or makes 
available to the Receiver information relating to that 
debit entry/The Receiver must also provide the RDFI 
with a written statement under penalty of perjury, 
pursuant to subsection 8.6.5.2 (Receiver's Written 
Statement Under Penalty of Perjury for POP Entries), 
that (1) the entry was not authorized, or (2) the source 
document for the entry is improper. An RDFI using 
this Return Reason Code must transmit the return entry 
by its ACH Operator's deposit deadline for the return 
entry to be made available to the ODFI no later than the 
opening of business on the banking day following the 
sixtieth calendar day following the Settlement Date of 
the entry. 



Rll Check Truncation Entry Return (Specify) 

To be used when returning a check truncation entry. This 
reason for return should be used only if no other return 
reason code is applicable. The RDFI should use the 
appropriate field in the addenda record to specify the 
reason for return (i.e., "exceeds dollar limit," "no match 
on ARP," "stale date," etc.). 



Rl 2 Account Sold to Another DFL A financial 
institution may continue to receive entries destined for an 
account that has been sold to another financial institution. 
Because the RDFI no longer maintains the account and is 
unable to post the entry, it should return the entry to the 
ODFI. 

R14 Representative Payee Deceased or Unable to 
Continue in that Capacity. The representative payee is 
a person or institution authorized to accept entries on 
behalf of one or more other persons, such as legally 
incapacitated adults or minor children. The representative 
payee is either deceased or unable to continue in that 
capacity. The beneficiary is not deceased. 

R15 Beneficiary or Account Holder (Other Than a 
Representative Payee) Deceased. (1) The beneficiary is 
the person entitled to the benefits and is deceased. The 
beneficiary may or may not be the account holder; or (2) 
The account holder (acting in a non-representative payee 
capacity) is an owner of the account and is deceased. 

R16 Account Frozen. The funds in the account have 
been made unavailable due to specific action taken by the 
RDFI or by legal action. 

Rl 7 File Record Edit Criteria (Specify). Some fields 
that are not edited by the ACH Operator are edited by the 
RDFI. If the entry cannot be processed by the RDFI, the 
field(s) causing the processing error must be identified in 
the addenda record information field of the return. 

R20 Non-transaction Account. The ACH entry destined 
for a non-transaction account would include (1) an 
account against which transactions are prohibited or 
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limited (e.g., Regulation D); or, (2) a pass-through where 
entry is for a credit union or thrift organization, and 
Regulation E descriptive requirements cannot be met. 



R21 In valid Company Identification. The identification 
number used in the Company Identification Field is not 
valid. This Return Reason Code will normally be used on 
CIE transactions. 

R22 Invalid Individual ID Number. The Individual ID 
Number of CIE or MTE type entries is used by the 
Receiver to identify the account. The Receiver has 
indicated to the RDFI that the number by which the 
Originator was identified is not correct. 

R23 Credit Entry Refused by Receiver. The Receiver 
may return a credit entry because one of the following 
conditions exists: (1) a minimum amount required by the 
Receiver has not been remitted; (2) the exact amount 
required has not been remitted; (3) the account is subject 
to litigation and the Receiver will not accept the 
transaction; (4) acceptance of the transaction results in an 
overpayment; (5) the Originator is not known by the 
Receiver; or (6) the Receiver has not authorized this credit 
entry to this account 

R24 Duplicate Entry. The Receiving DFI has received 
what appears to be a duplicate entry; i.e., the trace 
number, date, dollar amount and/or other data matches 
another transaction. This code should be used with 
extreme care. The Receiving DFI should be aware that if 
a file has been duplicated, the Originator may have 
already generated a reversing file to remedy the situation. 

R29 Corporate Customer Advises Not Authorized. The 

RDFI has been notified by the Receiver (non-consumer) 
that a specific transaction has not been authorized by the 
Receiver. 

R31 Permissible Return Entry (CCD and CTX only). 

The RDFI has been notified by the ODFI that the ODFI 
agrees to accept a corporate return entry (CCD and CTX) 
in accordance with section 8.3 (ODFI Agrees to Accept 
CCD or CTX Return) of the NACHA Operating Rules. 

R33 Return of XCK Entry. The RDFI determines at its 
sole discretion to return an XCK entry. This return reason 
code may only be used to return XCK entries. An XCK 
entry may be returned up to sixty (60) days after its 
Settlement Date. 

R3 7 Source Document Presented for Payment 
(adjustment entries) 

The source document to which an ARC entry or a POP 
entry relates has been presented for payment. The 
Receiver may request immediate credit from the RDFI for 
an ARC entry or a POP entry for the reason described 
above. The request must be made in writing within fifteen 
(15) days after the RDFI sends or makes available to the 
Receiver information relating to that debit entry. The 



Receiver must also provide the RDFI with a written 
statement under penalty of perjury that the source 
document was presented for payment. An RDFI using this 
return reason code must transmit the return entry by its 
ACH Operator's deposit deadline for the return entry to 
be made available to the ODFI no later than the opening 
of business on the banking day following the sixtieth 
calendar day following the Settlement Date of the ARC 
entry or the POP entry. 

R38 Stop Payment on Source Document (adjustment 
entries) 

The RDFI determines that a stop payment order has been 
placed on the source document to which the ARC entry 
relates. An RDFI using this Return Reason Code must 
transmit the return entry by its ACH Operator's deposit 
deadline for the return entry to be made available to the 
ODFI no later than the opening of business on the banking 
day following the sixtieth calendar day following the 
Settlement Date of the ARC entry to which the source 
document relates. 




The following return reason codes may be used by 
participating Federal Government Agencies to return 
Automated Enrollment entries. 

R40 Return of ENR Entry by Federal Government 
Agency (ENR only). The Federal Government Agency 
that received the Automated Enrollment entry has chosen 
not to accept ENR entries. DFIs/Receivers should contact 
the Agency outside the ACH system regarding the 
enrollment information. 

The following return reason codes relate to the contents 
of the addenda records associated with the ENR entry. 

R4I Invalid Transaction Code. The Transaction Code 
included in Field 3 of the Addenda Record is something 
other than "22 " (Automated Deposit for Demand Account 
Credit Records), "27" (Automated Payment for Demand 
Debit Account), "32" (Automated Deposit for Savings 
Account Credit Records), or "37" (Automated Payment 
for Savings Account Debit Records). The transaction 
code contained within the Payment Related Information 
Field of the addenda record is used to indicate the type of 
ACH entry that will be originated either by the DFFs 
account holder or the Federal Agency. 

Note : For direct deposit credit enrollments for Federal 
Government benefit payments, the Transaction Code 
contained within the Payment Related Information Field 
of the addenda record must contain either a "22" 
(Automated Deposit for Demand Credit Account Records) 
or a "32" (Automated Deposit for Savings Account Credit 
Records). Use of any other transaction code within this 
field will cause the enrollment entry to be returned by the 
Federal Government Agency. 
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R42 Routing Number/Check Digit Error. The routing 
number of the Receiver ' s financial institution contained 
within the Payment Related Information field of the 
addenda record is incorrect. The routing number and 
check digit for the Receiver's financial institution are 
necessary for the Federal Government Agency to transmit 
future ACH payments to the Receiver' s account. An 
invalid routing number and/or check digit will cause the 
enrollment entry to be returned by the Federal 
Government Agency. 

R43 Invalid DFI Account Number. The enrollee's 
account number at the DFI (c ontained within the P ayment 
Related Information Field of the addenda record) is either 
missing, exceeds 17 positions, or contains invalid 
characters. The enrollee's account number is necessary 
for the Federal Government Agency to transmit future 
ACH transactions to the enrollee. An invalid account 
number will cause the enrollment entry to be returned by 
the Federal Government Agency. 

R44 Invalid Individual ID Number/Identification 
Number. The enrollee's identification number contained 
within the Payment Related Information field of the 
addenda record is either invalid (e.g., contains more or 
fewer than 9 digits or is otherwise an invalid number), or 
it does not match a corresponding identification number 
in the Federal Agency' s records. The enrollee 's valid 
identification number is necessary for the Federal 
Government Agency to process the enrollment 
information. An invalid identification number or one not 
matching the Federal Agency's records will cause the 
enrollment entry to be returned by the Agency. 

R45 Invalid Individual Name/Company Name. The 

name of the enrollee provided in the Payment Related 
Information field of the addenda record either does not 
match a corresponding name in the Federal Agency's 
records, or it fails to include at least one alphameric 
character. The enrollee's name is necessary for the 
Federal Agency to process the enrollment information. 
An enrollee's name not notching the Federal Government 
Agency's records or not containing alphameric characters 
will cause the enrollment entry to be returned by the 
Agency. 

R46 Invalid Representative Payee Indicator. The 

Representative Payee Indicator Code included in the 
Payment Related Information field of the addenda record 
has been omitted or is not consistent with the Federal 
Agency's records. The Representative Payee Indicator 
code must be either a "zero" to denote that the payment 
will be sent to the Receiver, or a "one'' to denote that the 
payment will be sent to a representative payee on behalf 
of an entitled beneficiary. (Example: The Representative 
Payee Indicator Code is "zero" and Social Security's 
records indicate that payments should be sent to a 
representative payee on behalf of an entitled beneficiary.) 



Note : For direct deposit credit enrollments for Federal 
Government benefit payments, the Representative Payee 
Indicator field must contain a "0" (zero) or a "1 " (one). 
Any other code in this field will cause the enrollment 
entry to be returned by the Federal Government Agency. 

R47 Duplicate Enrollment The Federal Agency has 
received duplicate Automated Enrollment entries from the 
sameDFI. 

The following return reason codes may be used only for 
Re-presented Check Entries. 

R50 State Law Affecting RCK Acceptance 

• The RDFI is located in a state that has not adopted 
Revised Article 4 of me Uniform Commercial Code 
(1990 Official Text) and has not revised its customer 
agreements to allow for electronic presentment. 



OR 



• The RDFI is located in a state that requires all canceled 
checks to a specific type of account to be returned to 
the Receiver within the periodic statement. 

An RCK entry that is returned using this Return Reason 
Code must be transmitted by the RDFI to its ACH 
Operator no later than midnight of the second banking day 
following the banking day of receipt of the presentment 
notice. 

R51 Item is Ineligible, Notice Not Provided, Signature 
Not Genuine, Item Altered, or Amount of Entry Not 
Accurately Obtained from Item (adjustm ent entries) 

a An RCK entry may be considered to be ineligible if ( 1 ) 
the item to which the RCK entry relates is not an item 
within the meaning of Revised Article 4 of the Uniform 
Commercial Code (1990 Official Text); (2) the item is 
not a negotiable demand draft drawn on or payable 
through or at a Participating DFI, other than a Federal 
Reserve Bank or Federal Home Loan Bank; (3) the 
item does not contain a pre-printed serial number; (4) 
the item is in an amount of $2,500 or more; (5) the item 
does not indicate on the face of the document that it 
was returned due to "Not Sufficient Funds," "NSF," 
"Uncollected Funds," or comparable language; (6) the 
item is dated more than 180 days from the date the 
entry is being transmitted to the RDFI (i.e., the item to 
which the RCK entry relates is stale dated); (7) the item 
is drawn on a non-Consumer Account; or (8) the item 
has been previously presented more than two times in 
its physical form, or more than one time in its physical 
form and more than one time as an RCK entry. 



OR 
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The Originator did not provide notice as provided for 
within Article Three, subsection 3.6.2 (Notice 
Obligation). 



OR 



All signatures on the item to which the RCK entry 
relates are not authentic or authorized, or the item to 
which the RCK entry relates has been altered. 



OR 



'•■■ The amount of the RCK entry was not accurately 
obtained from the item. 

An RDFI using this Return Reason Code must transmit 
the return entry by its ACH Operator's deposit deadline 
for the return entry to be made available to the ODFI no 
later than the opening of business on the banking day 
following the sixtieth calendar day following the 
Settlement Date of the RCK entry to which the item 
relates. 



R52 Stop Payment on Item (adjustment entries) 
The RDFI determines that a stop payment order has been 
placed on the item to which the RCK entry relates. An 
RDFI using this Return Reason Code must transmit the 
return entry by its ACH Operator's deposit deadline for 
the return entry to be made available to the ODFI no later 
than the opening of business on the banking day following 
the sixtieth calendar day following the settlement date of 
the RCK entry to which the item relates. 

R53 Item and ACH Entry Presented for Payment 
(adjustment entries) 

In addition to an RCK entry, the item to which the RCK 
entry relates has also been presented for payment. The 
Receiver may request immediate credit from the RDFI for 
an RCK entry for the reason described above. The 
request must be made in writing within fifteen (15) days 
after the RDFI sends or makes available to the Receiver 
information relating to that debit entry. The Receiver 
must also provide the RDFI with a written statement under 
penalty of perjury, pursuant to subsection 8.6.5.3 
(Receiver's Written Statement Under Penalty of Perjury 
for RCK Entries), that both the RCK entry and the item to 
which it relates were presented for payment. An RDFI 
using this return reason code must transmit the return 
entry by its ACH Operator's deposit deadline for the 
return entry to be made available to the ODFI no later 
than the opening of business on the banking day following 
the sixtieth calendar day following the Settlement Date of 
theRCKentry. 



Codes to be Used for the Return ofCBR and PER Entries 

R80 Cross-Border Payment Coding Error. The cross- 
border entry is being returned due to one or more of the 
following conditions: 



• invalid Foreign Exchange Indicator; 

.• invalid ISO Originating Currency Code; 

• invalid ISO Destination Currency Code; 

• invalid ISO Destination Country Code; or 
•■ invalid Transaction Type Code. 

R81 Non-Participant in Cross-Border Program. The 

cross-border entry is being returned because the 
Originating Gateway Operator does not have an 
agreement with the ODFI to process cross-border entries. 

R82 Invalid Foreign Receiving DFI Identification. The 

reference used to identify the Foreign Receiving DFI of an 
outbound cross-border entry is invalid. 

R83 Foreign Receiving DFI Unable to Settle. The cross- 
border entry is being returned due to settlement problems 
in the foreign payment system. 

R84 Entry Not Processed by O GO. The cross-border 
entry has not been processed and is being returned at the 
OGO's discretion because the processing of such entry 
may expose the OGO to excessive risk. 

Processing Requirements 

Returns may be originated by the RDFI in automated or 
non-automated format. 

Automated Returns 

Automation is the preferred method for originating 
returns. An RDFI that wishes to originate returns in 
automated format must first: 

•'■ have the ability to generate returns in ACH format (see 
the Mapping chapter in Section IV of these Guidelines). 

•' fulfill the requirements of the ACH Operator to initiate 
transactions into the ACH system. 

RDFIs that are unable to generate automated returns 
should determine from ACH Operators what products and 
services are available for handling non-automated returns. 

Timing of Returns 

In general, return entries must be received by the RDFFs 
ACH Operator by its deposit deadline for the return entry 
to be made available to the ODFI no later than the 
opening of business on the second banking day following 
the Settlement Date of the original entry. For RCK 
entries, the RDFI must transmit the return entry to its 
ACH Operator by midnight of the second banking day 
following the banking day of receipt of the presentment 
notice. 

If a return entry is being initiated for R05 (effective 
March 1 8, 2005), R07, RIO, R37, R38, R5 1 , R52, or R53, 
the RDFI must transmit the adjustment entry so that the 
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adjustment entry is made available to the ODFI no later 
than the opening of business on the banking day following 
the sixtieth calendar day following the settlement date of 
the original entry. RDFIs need to be aware of return 
processing schedules offered by their ACH Operator in 
order to meet this requirement. All RDFIs should also be 
aware that ACH Operators offer return proces sing 
schedules that will allow return entries to be processed 
and settled earlier than required. For example, an RDFI 
could initiate a return the day after settlement of the 
original entry and receive settlement for the return on that 
day. ..■■■;■.■. 

Unauthorized Corporate Debits 

If a Receiver notifies its RDFI that a debit to its account 
was not authorized, the RDFI must return the entry (using 
Return Reason Code R29 - Corporate Customer Advises 
Not Authorized) so that it is received by the RDFFs ACH 
Operator by its deposit deadline for the return entry to be 
made available to the ODFI no later than the opening of 
business on the second banking day following the 
Settlement Date of the original entry. If that time frame 
has expired, the RDFI may (but is not required to) contact 
the ODFI and ask for permission to return the entry 
beyond the deadline based on the Receiver's claim that the 
debit is unauthorized. 



If the ODFI agrees to accept the return, the RDFI would 
initiate the return entry with the Return Reason Code R3 1 
-Permissible Return Entry. The RDFI should not use this 
code unless it has received permission from the ODFI to 
return the entry. Use of this code without the permission 
of the ODFI could result in a dishonor of me return entry. 

Extended Return Deadlines for Unauthorized/Improper 
Consumer Entries 

A consumer may notify an RDFI that a statement contains 
an ACH transaction that was not authorized, was 
originated after the authorization had been revoked, was 
ineligible for ACH origination, or was improperly 
originated. 

An unauthorized debit entry is an entry in which: 

• the written authorization requirements have not been 
followed; 

• a transaction was initiated in an amount greater than 
that authorized by the Receiver; 

.•■ a transaction was initiated for settlement earlier than 
authorized by the Receiver; or 

• with respect to ARC entries, (1) notice was not 
provided to the Receiver by the Originator in 
accordance with the requirements of the NACHA 
Operating Rules, (2) the entry was transmitted to an 
account of a Receiver who opted out of ARC check 



conversion activity, or (3) the amount of the ARC entry 
was not accurately obtained from the source document. 

An unauthorized debit does not include a debit entry 
initiated with fraudulent intent by the Receiver or any 
person acting in concert with the Receiver, nor does it 
include ACH transactions that were properly authorized 
but the goods or services received were not satisfactory to 
the consumer. 

Consumer debit entries returned by the RDFI as 
unauthorized will bear Return Reason Code RIO 
(Customer Advises Not Authorized, Notice Not Provided, 
Improper Source Document, or Amount of Entry Not 
Accurately Obtained from Source Document) and must be 
returned by the RDFI in such time and manner that the 
return is made available to the ODFI no later than the 
opening of business on the banking day following the 
sixtieth calendar day following the Settlement Date of the 
original entry. This return deadline also applies to debit 
entries for which the consumer Receiver had previously 
revoked his authorization for the transaction (Return 
Reason Code R07 - Authorization Revoked). 



At times, Originators may erroneously transmit ACH 
entries that are formatted using an incorrect SEC Code. 
This is in violation of the NACHA Operating Rules, 
Because the Rules require the RDFI to rely on the ODFI's 
warranty that the SEC Code included in the entry is 
proper, the RDFI is obligated to use the return rules and 
time frames associated with that particular SEC Code. 
Currently, an unauthorized debit to a consumer account 
where that entry incorrectly bears a corporate SEC Code 
must be returned in accordance with the return rules and 
time frames governing corporate transactions (that is, 
using Return Reason Code R29 within two banking days 
of the Settlement Date of the original entry). In such 
cases, the RDFI is typically precluded from automatically 
returning such an unauthorized debit because the return 
time frame for corporate entries will have lapsed before 
the consumer can receive his statement and notify his 
RDFI about the unauthorized debit to his account. 
Instead, the RDFI would be required to request 
permission from the ODFI to return the entry as a 
permissible return. 

Effective March 18, 2005, a new Return Reason Code 
R05 (Unauthorized Debit to Consumer Account Using 
Corporate SEC Code) will become available to RDFIs for 
the return of unauthorized debits transmitted to consumer 
accounts when those debit entries incorrectly bear a 
corporate SEC Code (i.e., CCD, CTX, or CBR). With the 
addition of this rule, the RDFI will be permitted to return 
all unauthorized debits to consumer accounts, regardless 
of SEC Code, within sixty days of the Settlement Date of 
the original entry, provided the RDFI has obtained a 
written statement under penalty of perjury from the 
consumer. 
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Ineligible/Improper Consumer Debit Entries 

RDFIs may also return entries that were ineligible for 
ACH origination or that were originated improperly. An 
ineligible or improper debit entry is an entry for which: 

• Ineligible RCK Entries: 

■■.':-■ the item to which the entry relates is ineligible to 
be initiated as an RCK entry (Return Reason Code 

- the required notice stating the terms of the re- 
presented check entry policy was not provided by 
the Originator in accordance with the requirements 
of the NACHA Operating Rules (Return Reason 
CodeRSl); 

- all signatures on the item to which the RCK entry 
relates are not authentic or authorized, or the item 
has been altered (Return Reason Code R51); 

- the amount of the RCK entry was not accurately 
obtained from the item (Return Reason Code 
R51);or 

■ - both the RCK entry and the item to which the 
RCK entry relates have been presented for 
payment (Return Reason Code R53). 

'• Improper ARC Entries : 

- the source document used for the debit entry is 
i^ 

- checks drawn on corporate or business 
accounts; 

- third-party checks; 

- demand drafts/third-party drafts that do not 
contain the signature of the Receiver; 

- credit card checks; 

- obligations of a financial institution (travelers 
checks, cashier's checks, official checks, money 
orders, etc.) 

■-■ checks drawn on the U.S. Treasury, a Federal 
Reserve Bank, or a Federal Home Loan Bank; 

- checks drawn oh a state or local government; 

- checks payable in a medium other than United 
States currency. 

- the source document was presented for payment 
(Return Reason Code R37), 

• Ineligible POP Entries: 

- the source document used for the debit entry is 
improper (Return Reason Code RIO): 

- checks drawn on corporate or business accounts; 

- third-party checks; 
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- credit card checks; 

- obligations of a financial institution (travelers 
checks, cashier's checks, official checks, money 
orders, etc.) 

- checks drawn on the U.S. Treasury, a Federal 
Reserve Bank, or a Federal Home Loan Bank; 

- checks drawn on a state or local government; 

- checks payable in a medium other than United 
States currency; 

- previously voided checks/sharedrafts used for 
prior POP entries. 



■ ■.-■■'■■'. the source document was presented for payment 
(Return Reason Code R37). 

An RDFI must establish internal procedures to obtain 
written statements under penalty of perjury when 
necessary. (NOTE : Account holders do not necessarily 
have to sign the written statement under penalty of perjury 
in person at the financial institution.) By initiating the 
adjustment entry for the transaction in question, the RDFI 
warrants that it has obtained a written statement under 
penalty of perjury from the consumer. The RDFI 
indemnifies each ODFI, ACH Operator, and ACH 
Association against any claims, demands, loss, liability, or 
expense resulting from the breach of this warranty. An 
RDFI may refer to the specific definition of what 
constitutes an unauthorized entry in its evaluation of a 
consumer's claim that an entry was not authorized. 

RDFIs should be aware, when recrediting their consumers 
for unauthorized or improper debit entries, that the 
requirement to obtain a written statement under penalty of 
perjury is the minimum requirement under the NACHA 
Operating Rules. An RDFI may choose, at its discretion, 
to obtain an affidavit from its account holder. When 
making the decision to use a written statement under 
penalty of perjury or an affidavit, it is important for 
RDFIs to note that some state laws require that all 
affidavits be notarized. With respect to a written 
statement under penalty of perjury, other states preclude 
a person from being charged with perjury unless he or she 
has taken an oath before an authorized public official, 
which, in most cases is a notary. An RDFI may wish to 
consult its legal counsel to determine which document is 
most appropriate for its use. 

Authorization Revoked vs. Stop Payment 

It is important for an RDFI to recognize the difference 
between a stop payment and revocation of authorization. 

Stop Payment 

Stop payment orders are allowed in the ACH system just 
as they are in the check system. With the exception of 
POP entries, Single-Entry WEB entries, and TEL entries, 
the consumer may order stop payments orally or in writing 
up to three days prior to the expected Settlement Date of 
the entry. For POP entries, Single-Entry WEB entries, and 
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TEL entries, the consumer must place the stop payment 
order in such time and in such manner that the RDFI has 
a reasonable opportunity to act on the stop payment order 
prior to acting on the entry. Just as a stop payment on a 
check is for one check only, a stop payment in the ACH 
Network is for one ACH payment only. A return is 
initiated with a Return Reason Code of R08. Because the 
R08 Code is not a request to stop all future payments, the 
RDFI and the consumer can expect subsequent payments 
to be initiated. Return entries initiated due to a stop 
payment order having been placed on the ACH entry must 
be transmitted to the RDFI's ACH Operator by its deposit 
deadline for the return entry to be made available to the 
ODFI no later than the opening of business on the second 
banking day following the settlement date of the original 
entry. 

Return Reason Codes R3 8 (Stop Payment on Source 
Document) and R52 (Stop Payment on Item) are used to 
return an ARC entry or an RCK entry, respectively, for 
which a stop payment has been placed on the source 
document/item to which the entry relates. In these 
circumstances, the RDFI must transmit a return entry 
using Return Reason Code R38 or R52 by its ACH 
Operator's deposit deadline for the return entry to be 
made available to the ODFI no later than the opening of 
business on the banking day following the sixtieth 
calendar day following the settlement date of the entry to 
whichthe item relates. 

Authorization Revoked 
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The Return Reason Code (R07) used to identify this type 
of return tells the Originator that there was once an 
authorization in place, but that authorization, in its 
entirety, has since been rescinded. As a result, all future 
entries related to this authorization must be stopped. In 
order to initiate subsequent entries, the Originator would 
need to obtain anew authorization from the Receiver. 
When using this code, the RDFI is warranting that it has 
obtained a written statement under penalty of perjury from 
the Receiver stating that the Receiver has revoked the 
authorization with the Originator. The RDFI should 
develop procedures to accept and retain copies of written 
statements under penalty of perjury. (Note: For additional 
information on written statements under penalty of 
perjury, refer to the chapter on Receiving Depository 
Financial Institutions in Section II of these Guidelines.) 

RDFIs should ensure that all customer service personnel 
understand the difference between stop payment orders 
and revocation of authorization. 

NACHA Operating Rules vs. Regulation E ~ Receiver's 
Right to Recredit and RDFI's Right to Adjustment 
(Return) 

Many ACH participants have expressed confusion over 
what they perceive is a conflict between the NA CHA 
Operating Rules and Regulation E with respect to the time 



frames for handling an unauthorized/improper consumer 
debit entry. It is important that RDFIs have an 
understanding of the requirements of the NACHA 
Operating Rules and Regulation E, as they are 
fundamentally different in scope, governing different 
parties to an ACH transaction and each having its own set 
of requirements and time frames. 

Regulation E addresses the banking relationship between 
an RDFI and its account holder with respect to electronic 
funds transfers. Within its purview, Regulation E defines 
the specific rights and obligations of both the consumer 
and the RDFI when dealing with, among other issues, 
claims of an unauthorized or erroneous electronic funds 
transfer. With respect to unauthorized or erroneous debit 
entries, Regulation E requires the consumer to notify its 
financial institution of an unauthorized or erroneous entry 
within sixty days of the date the statement is sent or made 
available to the consumer. Regulation E requires the 
RDFI to investigate the consumer's claim of an 
unauthorized/erroneous transaction and recredit the 
consumer, as appropriate. RDFIs should understand, 
however, that Regulation E provides no mechanism that 
may be used by the RDFI to return an 
unauthorized/erroneous entry to the ODFI. As a result, 
the RDFI would be forced to deal directly with the ODFI 
to recover funds recredited to the consumer. For the most 
current information on Regulation E, contact the Board of 
Governors of the Federal Reserve System, or refer to the 
section on Regulation E within the complete edition of the 
ACH Rules: A Complete Guide to Rules & Regulations 
Governing the ACH Network. 

Unlike Regulation E, which governs the relationship 
between RDFI and its consumer account holder, the 
NA CHA Operating Rules address the relationship between 
the ODFI and the RDFI with respect to processing ACH 
entries. These Rules impose certain obligations and 
liabilities on each financial institution and provide a 
mechanism through which an RDFI may return an entry 
(including an unauthorized consumer debit entry) to the 
ODFI. The NACHA Operating Rules permit an RDFI to 
recredit a consumer for unauthorized consumer debit entry 
(provided the RDFI obtains a written statement under 
penalty of perjury from the consumer) and return the entry 
to the ODFI, provided the return is transmitted by the 
RDFI in such time as to be made available to the ODFI no 
later than the opening of business on the banking day 
following the sixtieth calendar day following the 
settlement date of the entry. 

Although the Regulation E and NACHA time frames are 
different, they are not in conflict as they do not govern the 
same processes. RDFIs must be aware that, in some 
cases, the time frame in which an RDFI may return an 
unauthorized consumer debit entry via the ACH Network 
will have lapsed before the end of the time frame in which 
an RDFI must investigate a consumer's claim and recredit 
under Regulation E. In such situations, the RDFI will be 
unable to use the ACH return mechanism to make itself 
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whole and must seek reimbursement for funds reeredited 
to the consumer directly with the ODFI.'/. ■ 

Settlement of Return Entries 

Return entries are settled in the same manner as original 
entries; however, timing of settlement may vary 
depending on when the return is received at the ACH 
Operator. RDFIs should contact their ACH Operator for 
information on processing windows and deadlines for 
return settlement. 

Rejected Returns 

If a return entry cannot be processed, it will be returned to 
the RDFI. Returns that have been entered into the ACH 
system, either non-automated or automated, can be 
rejected for certain reasons and will be returned to the 
RDFI with a Return Reason Code used by ACH Operators 
(see RESPONSIBILITIES OF ACH OPERATORS 
section in this Chapter). These will be sent to the RDFTs 
Receiving Point with other ACH entries. All Receiving 
Points should be able to recognize these entries in order 
that the RDFI can handle them appropriately. 

Non-automated returns that cannot be entered into the 
ACH system will be returned to the RDFI. Procedures for 
the return of these entries may vary by ACH region. 

When a return is rejected by the ACH Operator, the 
Originator has not received the return; therefore, a delay 
has occurred, and the return may be untimely. RDFIs are 
encouraged to ensure that all entries are initiated 
appropriately, i.e., that all entries comply with ACH 
format specifications. 

General Guidelines For ACH Return Entries 



Only the exact dollar amount of the original entry may 
bereturned. 

Initiate only one return per entry to be returned. 

Return entries for valid reasons only. 

Always return the same type of entry; i.e., if you 
receive a credit, return a credit; if you receive a debit, 
return a debit. 

Always return all of the information that was sent on 
the original entry. 

Records of each return entry must be retained for six 
years . 

Remember, your return can be returned to you by the 
ACH Operator if it cannot be processed. Since the 
ODFI is unaware of these problems, the resubmitted 
entry could fail the timeliness test 



'.• The RDFI should check with its ACH Operator on 
procedures for sending non-automated returns (ACH 
Operators have specific procedures, and not all ACH 
Operators provide a service to accept non-automated 
returns and convert them to automated format) . 

2. RECEIVING DISHONORED RETURNS 

Returned entries can be dishonored by the ODFI for 
specific reasons (see RESPONSIBILITIES OF ODFI 
section in this chapter). When an RDFI receives a 
dishonored return (it will be included with other ACH 
entries received), it must take appropriate action within 
two banking days. The action taken by the RDFI can take 
three forms: 

' • For a return dishonored as untimely, the RDFI can 
contest the dishonor if it did return the entry in a timely 
manner (see part 3, Originating Contested Dishonored 
Returns). 

•.■ For a return dishonored as untimely, the RDFI must 
accept the dishonored return if it did return the entry in 
an untimely manner. At this point, the RDFI can 
attempt to post the entry to its customer's account. 
However, a non-postable entry, for example, NSF, must 
be accepted by the RDFI. 

■ • ■ For a return dishonored because it contained incorrect 
information, the RDFI can use the contested dishonor 
process to correct the information (see below). 

3. ORIGINATING CONTESTED DISHONORED 
RETURNS 

As indicated above, the RDFI can utilize the contested 
dishonored return process under certain conditions, as 
follows: 

To contest a Dishonored Return that claims the original 
return was untimely 

If a return has been dishonored by the ODFI as untimely, 
the RDFI should immediately perform the following 
research: 

> Determine the date on which settlement occurred for 
the original entry. 

. '• ■ Determine the appropriate course of action for 
returning the entry (see above, Timing of Returns ). 

•■■ Determine if the appropriate course of action was 
accomplished, for example, 

- if the return was received by the RDFI's ACH 
Operator by its deposit deadline for the return to be 
made available to the ODFI no later than the opening 
of business on the second banking day following the 
Settlement Date of the original entry, or 
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— if the return entry carried a Return Reason Code of 
R05 (effective March 18, 2005), R07, RIO, R37, 
R38, R51, R52, or R53, it was made available to the 
ODFI no later than the opening of business on the 
banking day following the sixtieth calendar day 
following the settlement date of the original entry. 

Once the research is completed, the RDFI can: 

• Contest the dishonor if the return was timely using the 
Contested Dishonored Return Code R73 (Timely 
Original Return). 

• Accept the dishonored return without further recourse 
to the ODFI. 

To correct a Dishonored Return that claims the original 
return contained incorrect information 

If a return has been dishonored because it contained 
incorrect information, the RDFI can correct the 
information by originating a Contested (Corrected) 
Dishonored Return. The RDFI uses the Contested 
Dishonored Return format with Return Reason Code R74 
(Corrected Return.) 

Processing Requirements 

Contested Dishonored Returns may be originated by the 
RDFI in automated or non-automated format. 

Automated Contested Dishonored Returns 

Automation is the preferred method for originating 
Contested Dishonored Returns. An RDFI that wishes to 
originate in automated format must: 

• have the ability to generate Contested Dishonored 
returns in ACH format; and 

• fulfill the requirements of the ACH Operator to initiate 
transactions into the ACH system (some ACH 
Operators require full Originator status). 

To Contest a Dishonored Return for other reasons 

The following Contested Dishonored returnreason codes 
can also be used to contest a dishonored return: 

R71 Misrouted Dishonored Return -the ODFI has sent 
the Dishonored return back to the wrong RDFI. This 
happens when the wrong Routing Number is inserted in 
the Entry Detail Record of the Dishonored return. The 
RDFI is unable to accept this entry. 

R72 Untimely Dishonored Return - the ODFI has not 
sent the Dishonored return to the RDFI within the 
designated time frame. (The ODFI has five banking days 
to dishonor a return.) 



RDFIs that are unable to generate automated contested 
dishonored returns should determine from ACH Operators 
what products and services are available for handling non- 
automated contested dishonored returns. 
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A. INTRODUCTION 



Once an entry or file of entries has been introduced into 
the ACH system, it cannot be recalled, but an erroneous 
or duplicate file can be reversed. If a single entry has 
been duplicated or originated erroneously, the ODFI may 
request the RDFI to return the entry. Reversal capability 
allows fast, efficient, and accurate recovery from an error. 
Various participants in the ACH system can initiate a 
reversal, depending upon the reason for that reversal. 

B. FILE REVERSALS 

File reversals may be originated to correct a duplicated 
file or an erroneous file in which substantially all of the 
entries were incorrect. A file can include an entire file or 
a number of batches that constitute a segment of a file. A 
reversing file will only reverse those batches which were 
duplicate or erroneous. 

1. DUPLICATE FILES 

A duplicate file is a file that was erroneously introduced 
into the ACH system twice. Duplicate files are exact in 
that all data within the two files is exactly the same, 
including effective entry dates, trace numbers, dollar 
amounts, etc. Therefore, the Receiver was erroneously 
paid (credits) or charged (debits) twice. 

2. ERRONEOUS FILES 

An erroneous file is one in which the information within 
a substantial number of the entries was incorrect. For 
example, the Receivers' account numbers could be all 
invalid, causing the entries to be posted or rejected 
incorrectly, or the do liar amount could have been 
incorrectly calculated, causing the Receiver to be paid or 
charged incorrectly. 
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3/ RESPONSIBILITIES OF THE RDFI 



It is critical that the RDFI be aware of the possibility that 
files can be duplicated or transmitted erroneously in the 
ACH Network. The following steps can be taken by the 
RDFI to assist in handling error situations appropriately: 

• Make sure that the error did not occur in-house. For 
example, if ACH entries were erroneously handled at 
the RDFI's Receiving Point (posted twice or otherwise 
mishandled), the error must be corrected in-house. 

. • . ■ Be familiar with how to identify a duplicate or 
erroneous file. 

- A duplicate file can result in entries being duplicated 
on an ACH printout or entry register. 

- A duplicate debit file could cause an unusual number 
of rejected items for insufficient funds. 

' - An erroneous file could also cause an unusual 
number of exception items, especially if the 
information that is erroneous is utilized for posting 
the entries. 

• Make sure that duplicate or erroneous transactions are 
returned appropriately. For example, if a duplicate 
entry was returned, the reversal for that entry should 
also be returned. 

• If in doubt, call the ACH Operator or ACH Association 
for more information. If a large file has been 
duplicated or originated erroneously, the RDFI can very 
often determine what course of action is appropriate by 
calling for additional information. 

Where can a duplication or error occur? 



A duplicate or erroneous file can be introduced anywhere 
in the flow of entries through the ACH system (see 
below). 

How can an RDFI recognize a reversal? 

The word REVERSAL is contained in the first eight 
positions of the Company Entry Description Field. 

4. GENERAL INSTRUCTIONS 

It is the responsibility of the party that originated the 
duplicate or erroneous file to reverse that file. Each 
reversing file must be in the format required by ACH 
specifications (see the Mapping chapter in Section IV of 
these Guidelines). Following is a list of responsibilities 
for each participant when a file is reversed due to 
duplication or error. 



Originaior/ODFI 

• Initiate the reversing file so that it can be delivered or 
made available to the RDFI(s) within 5 banking days 
after the Settlement Date for the entries within the 
duplicate or erroneous file. 

•Place the word "REVERSAL" (left justified) in the 
Company Entry Description Field of each 
Company/Batch Header Record. 

• Transmit the file to the Originating ACH Operator 
within 24 hours ofthe discovery of the error. 

• If the file is reversing an erroneous file, initiate a 
correcting with the reversing file. 

Originating ACH Operator 

• Initiate the reversing file so that it can be delivered or 
made available to the RDFI(s) within 5 banking days 
after the Settlement Date for the duplicate or erroneous 
file. 

• Place the word "REVERSAL" (left justified) in the 
Company Entry Description Field of each 
Company/Batch Header Record. 

• Transmit the file to the Receiving ACH Operator or 
RDFI within 24 hours ofthe discovery ofthe error. 

• Notify each ODFI concerned with the duplication or 
error. 

• If the file is reversing an erroneous file, a correcting file 
must be initiated with the reversing file. 




Receiving ACH Operator 

8 Initiate the reversing file in order that it can be 
delivered or made available to the RDFI(s) within 5 
banking days after the Settlement Date for the duplicate 
or erroneous file. 

• Place the word "REVERSAL" (left justified) in the 
Company Entry Description Field of each 
Company/Batch Header Record. 

• Transmit the file to the RDFI within 24 hours ofthe 
discovery of the error. 

• Notify each Originating ACH Operator directly 
concerned with the duplication or error. 

• If the file is reversing an erroneous file, a correcting file 
must be initiated with the reversing file. 
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Authorization 

The rules and requirements for authorization do not apply 
for reversing files. 

Additional Suggestions for Action 

The origination of duplicate and erroneous files is clearly 
an exception condition that can cause confusion and 
mishandling of ACH entries. The best protection against 
error is to ensure that procedures are in place to reduce or 
eliminate the possibility that duplicate or erroneous files 
will be originated. All participants in the ACH system 
should: 

• take steps to ensure that all files are originated 
correctly; 

• establish procedures to identify errors quickly; and 

• institute methods to initiate reversing files immediately, 
when necessary. 

If a file is duplicated or originated erroneously, there are 
certain steps that a participant can take to assist other 
parties that may be affected, such as: 



• ensuring that appropriate personnel are aware that an 
error has occurred and are aware of the correcting 
action taken; 

• contacting as many parties as possible to advise them of 
the error (ACH Operator, ACH Association, RDFIs) 
and of the correcting action taken; and, 

• establishing procedures to reduce the possibility that 
the same error can happen again. 

C. RECLAMATIONS FOR BENEFIT PAYMENTS 

An Originator or ODFI may initiate a reclamation entry 
for pension, annuity or other benefit payments by PPD, as 
provided for in sections 2.6 (Reclamation Entries) and 4.8 
(Liability of RDFI for Benefit Payments) of the NACHA 
Operating Rules, if V 

i) the Receiver is deceased; and 

ii) neither the Receiver's estate nor any other 

account holder is entitled to the payment. 

The RDFI's liability in such a case is limited to the lesser 

of: .. . 

• the amount of the payments the Receiver was not 
entitled to receive; or 

• the amount in the Receiver's account at the time the 
RDFI receives a reclamation entry or written demand 



for payment from the ODFI or the Originator and has 
had a reasonable opportunity to act upon the demand. 

NOTE : An RDFI may agree to some other amount of 
liability in an agreement with the Originator. The 
agreement must state on its face that it is a master 
agreement applicable to all pension, annuity or other 
benefit payments sent by the Originator to the RDFI for 
the benefit of all Receivers having accounts at the RDFI, 

The reclamation entry is a debit entry that may be 
originated in an amount equal to or less than the pension, 
annuity, or other benefit payment to which the reclamation 
relates. 

The reclamation entry shall also contain: 

..• the name of the Receiver; 

8 the deceased Receiver's account number; 

•■ the exact amount of the entry being reclaimed; 

• the approximate date the entry being reclaimed was 
initiated; and 

'•■ the word RECLAIM in the first eight positions of the 
Company Entry Description Field of the 
Company/Batch Header Record. 

The reclamation entry or written demand must be sent 
within five banking days after the Originator receives 
notice of the Receiver's death or within 15 banking days 
after the Originator receives a returned reclamation entry. 

D. ODFI REQUESTS FOR RETURN 

If the Originator has originated a single entry in error, the 
ODFI may request the RDFI to return the entry. An entry 
originated in error is an entry that is a duplicate of an 
entry previously issued by the Originator or ODFI that 
orders payment to a Receiver not intended to receive 
payment from the Originator or orders payment in an 
amount that differs from that amount the Receiver was 
entitled to receive from the Originator. 

The ODFI, not the Originator, should make the request to 
the RDFI because the ODFI warrants the appropriateness 
of the request and indemnifies the RDFI against loss. 

The RDFI may agree to return the entry, but it is not 
required to do so. If the RDFI does agree to return the 
entry, it may ask for a letter of indemnification from the 
ODFI prior to returning the entry. When the entry is 
returned, the RDFI should use the Return Reason Code 
R06 (Returned at the Request of the ODFI), 
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E. REVERSING ENTRIES ■ ■;. 

An Originator that originates a payment in error may 
originate a reversing entry . An erroneous entry is an entry 
that (1) is a duplicate of an entry previously initiated by 
the Originator or ODFI, (2) orders payment to or from a 
Receiver not intended to be credited or debited by the 
Originator, or (3) orders payment in a dollar amount 
different than was intended by the Originator. A reversing 
entry may be initiated under the following conditions: 

a Only an Originator may initiate a reversing entry. 

•A reversing entry is a debit or credit to correct a 
previous erroneous credit or debit. 

• As required by the NACHA Operating Rules, the 
Originator must notify the Receiver of and the reason 
for the reversing entry no later than the settlement date 
of the reversing entry. This will ensure that Receivers 
are made aware of ACH reversal activity to their 
accounts prior to the receipt of their periodic account 
statements . The NA CHA Operating Rules do not 
prescribe the method (i.e., mail, telephone, fax, etc.) by 
which Originators must provide notice to Receivers; 
instead, the choice of method is at the discretion of the 
Originator. 

• The reversing entry must be transmitted to the RDFI by 
midnight of the fifth banking day following settlement 
of the erroneous entry. 

• The advance notification rule for variable amount 
debits and the rules governing authorization 
requirements do not apply to reversing entries. 
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Two Standard Entry Class Codes are available for use by 
ACH participants which allow Originators to request an 
acknowledgment from the RDFI that a corporate credit 
entry has been received and that the RDFI will attempt to 
post the payment to the Receiver's account. 

A. INTRODUCTION 

The ACK and ATX Standard Entry Class Codes provide 
the platform for state and Federal government agencies 
and other corporate users to utilize the ACH Network for 
acknowledgment purposes. 



An acknowledgment entry is a non-dollar transaction 
transmitted by the RDFI in response to a request for an 
acknowledgment contained within the forward CCD or 
CTX credit entry. The ACK format is used by the RDFI 
to acknowledge the receipt of entries originated using the 
CCD format, and the ATX format will be used by the 
RDFI to acknowledge the receipt of entries originated 
using the CTX format. 

Use of the ACH acknowledgment process is optional for 
all participants, enabling corporations and financial 
institutions to utilize and/or provide ACH 
acknowledgment services based upon their individual 
organizations' business needs. 

R. RESPONSIBILITIES OF ORIGINATORS 

As the ACH acknowledgment process is an optional 
service for all ACH participants, Originators and 
Receivers wishing to exchange acknowledgments via the 
ACH Network will need to address the use of 
acknowledgment entries in their trading partner 
agreements. Originators should also be aware that the 
ODFI and RDFI involved in the payment process may, but 
are not required to, receive and process acknowledgment 
entries on behalf of their corporate customers. As a result, 
Originators choosing to utilize the acknowledgment 
process should address the use of the acknowledgment 
process in their Originator-ODFI agreements. 

Request for Acknowledgment 

An Originator may request that an acknowledgment entry 
be transmitted by the RDFI in response to a CCD or CTX 
credit entry by placing "AK" within the Discretionary 
Data field of the CCD or CTX entry for which the 
acknowledgment is desired. An RDFI which supports the 
acknowledgment process will transmit an 
acknowledgment entry with the Standard Entry Class 
Code "ACK" to the ODFI in response to a CCD entry for 
which an acknowledgment entry is requested. An 
acknowledgment entry with the Standard Entry Class 
Code "ATX" will be transmitted by the RDFI in response 
to a CTX entry for which an acknowledgment entry is 
requested. It should be noted that, in order for the 
Originator to receive the requested acknowledgment, both 
the ODFI and the RDFI of the entry must support the 
appropriate acknowledgment formats. Originators may 
wish to consider whether they need to develop a process 
to identify arid react to situations in which a requested 
acknowledgment entry is not received. 

An RDFI which supports the ACH acknowledgment 
process will transmit an ACK or ATX entry so that it is 
made available to the ODFI no later than the opening of 
business on the second banking day following the 
settlement date of the CCD or CTX entry to which the 
acknowledgment relates. An ACK or ATX entry 
transmitted by the RDFI in response to a request for an 
acknowledgment may be accompanied by one optional 
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Addenda Record. The Addenda Record contains an 80- 
character Payment-Related Information field, within 
which an ANSI ASC X12 REF (Reference) data segment 
may be entered which includes information about the 
acknowledgment as agreed to by the trading partners. 



■ 



Refused Acknowledgment Entries 

In the event that an Originator receives an ACK or ATX 
entry that is transmitted to it in error by the RDFI or that 
contains incorrect information, the Originator may request 
its ODFI to transmit a refused acknowledgment entry to 
the RDFI in accordance with the requirements of the 
NACHA Operating Rules. A refused acknowledgment 
entry (refused ACK or refused ATX) should be 
transmitted by the ODFI within fifteen days of the 
settlement date of the misrouted or erroneous 
acknowledgment entry. 



C; RESPONSIBILITIES OF ODFIs 

The ACH acknowledgment process is an optional service 
for all ACH participants. ODFIs may, but are not 
required to, receive and process acknowledgment entries 
on behalf of their corporate Originators. ODFIs choosing 
to provide ACH acknowledgment services should review 
their Originator agreements to ensure that the use of the 
ACH acknowledgment process is addressed. ODFIs 
should ensure that their Originators understand that, in 
order to receive an acknowledgment entry in response to 
its request, the RDFI must also have agreed to provide 
ACH acknowledgment services. 

Request for Acknowledgment 

ODFIs choosing to provide ACH acknowledgment 
services for their corporate Originators will need to ensure 
that their ACH origination software has been modified to 
accommodate the transmission of a request for an 
acknowledgment entry within the forward CCD or CTX 
entry (i.e., placement of "AK" within the Discretionary 
Data field of the CCD or CTX Entry Detail Record). 

An RDFI which supports the ACH acknowledgment 
process will transmit an ACK or ATX entry so that it is 
made available to the ODFI no later than the opening of 
business on the second banking day following the 
settlement date of the CCD or CTX entry to which the 
acknowledgment relates. An ACK entry will be 
transmitted by the RD>FI in response to a CCD entry for 
which an acknowledgment is requested. An ATX entry 
will be transmitted by the RDFI in response to a CTX 
entry for which an acknowledgment is requested. Both 
ACK and ATX entries may be accompanied by one 
optional Addenda Record. The Addenda Record contains 
an 80-character Payment-Related Information field, within 
which an ANSI ASC X12 REF (Reference) data segment 
may be entered which includes information about the 
acknowledgment as agreed to by the trading partners. 



Refused Acknowledgment Entries 

ODFIs providing ACH acknowledgment services to their 
corporate Originators should develop the capability to 
identify and react to acknowledgment entries that are 
transmitted by the RDFI in error or contain incorrect 
information. The ODFI may transmit a refused 
acknowledgment entry to the RDFI in accordance with the 
requirements of the NACHA Operating Rules. A refused 
acknowledgment entry (refused ACK or refused ATX) 
should be transmitted by the ODFI within fifteen days of 
the settlement date of the misrouted or erroneous 
acknowledgment entry. 

D. RESPONSIBILITIES OF RDFIs 

RDFIs may, at their option, provide ACH 
acknowledgment services on behalf of their corporate 
Receivers. RDFIs choosing to provide such services 
should address the provision of these services in their 
agreements with their corporate Receivers. RDFIs will 
need to develop the capability to identify acknowledgment 
requests based on the presence of "AK" within the 
Discretionary Data field of the CCD or CTX Entry Detail 
Record. 

Request for Acknowledgment 

An RDFI which supports the ACH acknowledgment 
process must transmit, within two banking days of the 
settlement date of the CCD or CTX entry to which the 
acknowledgment entry relates, an ACK or ATX entry to 
the ODFI. An RDFI will transmit an ACK entry in 
response to a CCD entry for which an acknowledgment is 
requested, and an ATX entry in response to a CTX entry. 
An ACK or ATX entry transmitted by the RDFI in 
response to a request for an acknowledgment may be 
accompanied by one optional Addenda Record. The 
Addenda Record contains an 80-character Payment- 
Related Information field, within which an ANSI ASC 
X 1.2 REF (Reference) data segment may be entered which 
includes information about the acknowledgment as agreed 
to by the trading partners. 

Refused Acknowledgment Entries 



RDFIs should be aware that ACK or ATX entries may be 
refused by the Originator/ODFI in the event that the entry 
is misrouted or contains incorrect information. Software 
modifications may be necessary to identify and process 
refused ACK/ATX entries, which should be transmitted 
by the ODFI to its ACH Operator within fifteen days of 
the settlement date of the misrouted or erroneous 
acknowledgment entry relates. 
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consumer's account by his or her RDFI. In most cases, 
the PPD debit will contain the name of the company to be 
paid (e.g. for bill payment transactions, the biller) in the 
Company Name Field, to assist the consumer in account 
reconciliation. (See illustration below.) 



A/ INTRODUCTION 

The CIE format was developed in 1979 to support 
consumer bill payment transactions initiated by the 
individual through their financial institution. At that time, 
these types of payments were typically originated over the 
telephone. Since the 1970s, many technological advances 
have impacted home banking and electronic consumer bill 
payment transactions. As a result of these advances, 
Third-Party Service providers currently offer bill payment 
services to both consumers and financial institutions. In 
response to these developments in the consumer bill 
payment environment, modifications were made to the 
CIE format in 1997 to more effectively meet the needs of 
billers and Third-Party Service Providers utilizing this 
payment mechanism. 

B. CUSTOMER-INITIATED ENTRIES (CIE) 

Use of the CIE Standard Entry Class Code is limited to 
credit applications in which the consumer initiates the 
transfer of funds owed to a company, typically through the 
use of some type of home banking product. The Third- 
Party Service Provider, at the instruction of the consumer, 
initiates a CIE credit entry to the biller for the amount 
owed by the consumer. The consumer's account is 
subsequently debited by the Third-Party Service Provider 
in the amount of the payment made to the biller using a 
PPD debit entry. 

A typical example of the use of the CIE format occurs 
when the consumer has contracted with a Third-Party 
Service Provider to process the payment. In this example, 
the consumer provides payment instructions to the Third- 
Party Service Provider, which acts on behalf of the 
consumer. The Third-Party Service Provider, through its 
ODFI, originates two transactions to complete the 
consumer's payment instruction. A CIE credit entry will 
be initiated by the Third-Party Service Provider to the 
biller for the amount owed by the consumer, and a debit 
entry will be transmitted by the Third-Party Service 
Provider to the consumer's account for the funds paid to 
the biller on behalf of the consumer. 

Once the CIE credit is received and posted by the biller's 
RDFI, the Receiver (the biller) will update its accounts 
receivable information based on the payment information 
contained within the CIE credit entry. The offsetting PPD 
debit to the consumer's account will be applied to the 
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In some situations, the consumer's financial institution is 
also the provider of the bill payment service. The 
consumer issues payment instructions by telephone, 
personal computer, screen-based telephone, or other 
devices directly to the ODFI. The ODFI debits the 
Originator's account through an internal transfer and 
transmits a CIE credit entry through the ACH Operator to 
the RDFI for credit to the Receiver's (biller's) account 
The RDFI notifies the Receiver of the receipt of the credit 
item and the Receiver (biller) updates its accounts 
receivable information. 

The consumer's financial institution (ODFI) may choose 
to utilize a bill payment service provider for accepting the 
consumer's instructions while itself maintaining control of 
the payment processing function. In this situation, the 
consumer issues payment instructions to the bill payment 
service provider, which forwards those instructions to the 
ODFI on behalf of the consumer. The ODFI subsequently 
debits the Originator's account through an internal 
transfer and transmits a CIE credit entry through the ACH 
Operator to the RDFI for credit to the Receiver's (biller's) 
account. The RDFI notifies the Receiver of the receipt of 
the credit item and the Receiver updates their account 
receivables. 

In accordance with the requirements of the NACHA 
Operating Rules y ACH Operators return all CIE debit 
entries that are not reversals to correct erroneous credit 
entries to the ODFIs from which they were originated. 
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These entries will be returned by the originating ACH 
Operator bearing the Return Reason Code R35 (Return of 
Improper Debit Entry). Because the CIE is defined as a 
credit entry under the NACHA Operating Rules, CIE debit 
transactions, with the exception of re versals, should not be 
transmitted. 

C. FORMATTING REQUIREMENTS 

X. CIE COMPANY/BATCH HEADER RECORD 

When initially developed, specific information relating to 
the biller was provided within the Company/Batch Header 
Record in order to assist in the processing of consumer 
bill payment entries. As the Company/Batch Header 
Record was originally intended for use with CIE 
transactions, the biller 's name was placed within the 
Company Name field, codes of significance to the 
Originator and/or ODFI were placed within the Company 
Discretionary Data field, and the biller 's identification 
number was placed within the Company Identification 
field. 

When faced with customer service inquiries or concerns 
relating to processing errors, however, billers found that 
the information contained within these fields was 
insufficient to enable them to respond to these 
circumstances efficiently. 

To facilitate a biller's efforts to contact a bill payment 
service provider concerning a customer inquiry or error 
investigation, the definitions for the use of the Company 
Name, Company Discretionary Data, and Company 
Identification fields in the Company/Batch Header Record 
were revised for use with CIE transactions to provide the 
biller with specific information about the bill payment 
service provider transmitting the entry. The Company 
Name field now provides the biller with the bill payment 
service provider's name, the Company Discretionary Data 
field conveys the biller's name, and the Company 
Identification field provides the bill payment service 
provider's identification number. 

2/ CIE ADDENDA RECORD 

CIE entries may be accompanied by one "05" Addenda 
Record. To accommodate changes in the consumer bill 
payment environment, the contents of the Payment- 
Related Information field of the CIE addenda record allow 
for the use of any payment-related ANSI ASC X12 data 
segment. This enables billers and bill payment service 
providers to transmit specific information related to the 
payment which is most useful to them when processing 
CIE entries, such as consumer name or address, or other 
information which would further assist the biller in 
processing the payment. 

The specific ANSI ASC X12 data segments that will be 
transmitted within the Payment Related Information field 
of the optional Addenda Record are decided upon by 



agreement between the bill payment service provider and 
the Biller. Information transmitted between the bill 
payment service provider and biller may, for example, 
include a name, account number with the biller, additional 
address information, etc. As many billers have already 
implemented systems that support ANSI ASC X12 
information, these changes will assist in the posting of 
consumer bill payment transactions. 

For Example: 

Nl*BY*JohnSmith*ZZ*123456789\N4**VA*20170\ 

In the above example, the Nl (Name) and N4 
(Geographic Location) data segments are used to convey 
consumer name, account number, state, and postal code 
data to further identify the consumer to the biller. 

When determining which segments should be included 
remember that the Payment Related Information field is 
limited to 80 characters and many ANSI ASC XI 2 data 
segments have variable length fields. For example, the 
Nl segment can have a minimum of 10. and a maximum of 
63 characters if all elements are used and the N4 segment 
can contain a minimum of .13 and a maximum of 82 
characters (ANSI ASC X12 Version Release 3060). 
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A. INTRODUCTION 



This chapter addresses issues relating to ACH origination 
and ACH receipt when the Originator, ODFI, or RDFI use 
the services of a Third-Party Service Provider for all or 
part of the process of handling ACH entries. A Third- 
Party Service Provider is an organization other than an 
Originator, ODFI, or RDFI that performs a function of 
ACH processing on behalf of the Originator, the ODFI or 
the RDFI. A function of ACH processing could be the act 
of creating an ACH file, on behalf of an Originator or 
ODFI or acting as a Sending Point or Receiving Point on 
behalf of an ODFI or RDFI, respectively. A Third-Party 
Service Provider could also take on the role of a Third- 
Party Sender, acting as an intermediary between the ODFI 
and the Originator with respect to the initiation of ACH 
transactions. The organization acting as a Third-Party 
Service Provider could be a data processing service 
bureau, correspondent bank, payable through bank, or 
simply a financial institution acting on behalf of another 
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financial institution. A more detailed discussion of the 
various roles played by Third-Party Service Providers 
follows this introduction. . 

This chapter discusses the processing of ACH transactions 
only. The settlement function is discussed within Section 
II, Participant Relationships and Responsibilities, in these 
Guidelines. 



It is important to realize that the NA CHA Operating Rules 
relate to financial institution participants. Use of a Third- 
Party Service Provider as a processing agent does not 
relieve the financial institution of its obligations under the 
N ACH A Operating Rules, nor dots it change the timing 
when actions must be taken, e.g., use of a third party does 
not modify the returns deadline. Therefore, the reader 
should have a thorough understanding of the issues 
outlined in Section II, Participant Relationships, prior to 
reading this chapter. The information in this chapter is 
not intended to stand alone; rather, it is intended to 
identify additional issues that need to be addressed by the 
Originator, ODFI, and RDFI when Third-Party Service 
Providers are used. 

B. THE ROLE OF THE THIRD-PARTY SERVICE 
PROVIDER 

As the ACH Network has evolved, Third-Party Service 
Providers have taken on larger and more complex roles in 
the processing of ACH transactions. To properly 
understand the impact of rule provisions on Third-Party 
Service Providers, it is essential to have a clear 
understanding of the specific roles Third-Party Service 
Providers play in the ACH Network and to understand 
clearly the distinction between a Third-Party Service 
Provider and an Originator. 

e Originator 

The definition of an Originator clearly distinguishes 
between an Originator of an ACH entry or file and a 
Third-Party Service Provider to whom some portion of 
the Originator's ACH processing requirements are 
outsourced. For purposes of the Rules, an Originator is 
defined as: 

(1) an entity that has authorized an ODFI to send or 
transmit^ for the account of that person, (i) a 
credit entry to the account of a Receiver with an 
RDFI to effect a payment from that person to the 
Receiver, or (ii) a debit entry to the Receiver's 
transaction account or general ledger account 
with an RDFI in order to effect a payment from 
the Receiver to that person; or 

(2) an entity that has authorized a Third-Party 
Sender to send or transmit to an ODFI for the 
account of that, or another, Third-Party Sender 
(i) a credit entry to the account of a Receiver 
with an RDFI in order to effect a payment from 



that person to the Receiver, or (ii) a debit entry 
to the Receiver's transaction account or general 
ledger account with an RDFI in order to effect a 
payment from the Receiver to that person. 

The Originator is the party with whom the Receiver has 
a contractual relationship and to or from whom funds 
are ultimately owed. In some situations, the Originator 
may enter into a contractual agreement with a Third- 
Party Service Provider, such as a payroll processor or 
other type of service provider, to process the company's 
payments where the Third-Party Service Provider, 
rather than the ultimate Originator of the payments, has 
the contractual relationship with the ODFI and against 
whose account funds are settled. While this business 
model is commonplace in today's payments 
environment, it is important that ACH participants 
recognize that the Third-Party Service Provider is not 
the Originator of the transactions. 

Third-Party Service Provider 

A Third-Party Service Provider is an entity other than 
an Originator, ODFI, or RDFI that performs any 
functions on behalf of the Originator, the ODFI, or the 
RDFI with respect to the processing of ACH entries, 
including, but not limited to, the creation of ACH files. 

.-.'■ Sending Point 

Third-Party Service Providers may act as Sending 
Points on behalf of a Participating DFI. A Sending 
Point is an entity that transmits entries to an ACH 
Operator on behalf of an ODFI. A Sending Point 
may be an ODFI acting on its own behalf, or a 
Participating DFI, a commercial data processing 
service organization, or a person operating a data 
transmission facility that acts on behalf of one or 
more ODFIs. (NOTE: The NACHA Operating 
Rules require an agreement between the ODFI and 
the Sending Point when a Sending Point is used by 
the ODFI to transmit ACH entries to the ACH 
Operator on its behalf. ) 

- Receiving Point 

Third-Party Service Providers may also act 
Receiving Points on behalf of a Participating DFI. 
A Receiving Point is an entity that receives entries 
from an ACH Operator on behalf of an RDFI. A 
Receiving Point may be an RDFI acting on its own 
behalf, a Participating DFI, a commercial data 
processing service organization, or a person 
operating a data transmission facility that acts on 
behalf of one or more RDFIs. 

Third-Party Sender 

A Third-Party Sender is a Third-Party Service Provider 
that is not an Originator and that has authorized an 
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ODFI or another Third-Party Sender to transmit, for the 
account of the Third-Party Sender or another Third- 
Party Sender, (i) a credit entry to the account of a 
Receiver with an RDFI in order to effect a payment 
from the Originator to the Receiver, or (ii) a debit entry * 
to the Receiver's transaction account or general ledger 
account with an RDFI in order to effect a payment from 
the Receiver to the Originator. 




Third-Party Senders are a subset of Third-Party Service 
Providers. That is, a Third-Party Sender is always a 
Third-Party Service Provider that acts on behalf of an 
Originator, but a Third-Party Service Provider does not 
always act as a Third-Party Sender. A Third-Party 
Service Provider is considered to be a Third-Party 
Sender when it acts as an intermediary between the 
ODFI and the Originator and there is no contractual 
agreement between the Originator and the ODFI. In 
any circumstance in which an Originator utilizes the 
services of a Third-Party Service Provider but has also 
executed a contractual agreement directly with the 
ODFI, the Third-Party Service Provider would not be 
considered a Third-Party Sender and would not be 
subject to the rule provisions governing Third-Party 
Senders. 

The following examples are provided to help clarify the 
specific circumstances in which a Third-Party Service 
Provider is also considered to be a Third-Party Sender. 

Example #1 



An employer contracts with ABC Payroll to handle its 
payroll processing. ABC Payroll has a contractual 
agreement with its own financial institution, MegaBank, 
to originate ACH activity on its behalf, and ABC Payroll's 
account at MegaBank is credited or debited by MegaBank 
for settlement of the ACH transactions processed by ABC 
Payroll. In this example, there is no relationship between 
the employer and MegaBank, and they do not have a 
contractual agreement between them for the origination of 
ACH payments. Instead, ABC Payroll is an intermediary 
between the employer and MegaBank. 

It is important to recognize that the employer in this 
example is the Originator of the payroll file because it is 
legally obligated to pay its employees, the Receivers. 
ABC Payroll is a Third-Party Service Provider performing 
the function of creating the payroll file on behalf of the 
Originator and transmitting it to the ODFI. In this 
scenario, ABC Payroll is also a Third-Party Sender 
because it is acting as an intermediary between the 
employer (the Originator) and MegaBank (the ODFI) and 
no contractual agreement exists between the ODFI and the 
Originator. 

Example # 2 

An employer contracts with ABC Payroll to handle its 
payroll processing. ABC Payroll formats the ACH file on 



behalf of the employer and forwards it on to MegaBank, 
with which the employer has a contractual agreement to 
originate ACH activity on its behalf. In this case, the 
employer holds an account with MegaBank that is 
credited or debited by MegaBank for settlement of the 
ACH transactions processed by ABC Payroll on the 
employer's behalf 

The employer in this example is the Originator of the 
payroll file because it is legally obligated to pay its 
employees, the Receivers. ABC Payroll is a Third-Party 
Service Provider performing the function of creating the 
payroll file on behalf of the Originator and transmitting it 
to the ODFI. In this scenario, however, ABC Payroll is 
not a Third-Party Sender because a direct contractual 
agreement exists between the ODFI and the Originator 
that binds the employer to the NACHA Operating Rules. 

Example # 3 

An employer contracts with ABC Payroll to handle its 
payroll processing. ABC Payroll has further contracted 
with ACH Pay Service Provider for the origination of its 
ACH processing into the ACH Network. ACH Pay 
Service Provider has a contractual agreement with its own 
financial institution, MegaBank, to originate ACH activity 
on its behalf, and ACH Pay Service Provider's account at 
MegaBank is credited or debited by MegaBank for the 
settlement of transactions processed by ACH Pay Service 
Provider. In this example, there is no relationship 
between the employer and MegaBank, and they do not 
have a contractual agreement between them for the 
origination of ACH payments. Similarly, there is no 
contractual agreement between ABC Payroll and 
MegaBank for the origination of ACH payments. In this 
case, there are two intermediaries (ABC Payroll and ACH 
Pay Service Provider) between the employer and 
MegaBank. 

The employer in this example is the Originator of the 
payroll file because it is legally obligated to pay its 
employees, the Receivers. ABC Payroll and ACH Pay 
Service Provider are both Third-Party Service Providers 
acting as Third-Party Senders because they are acting as 
intermediaries between the employer (the Originator) and 
MegaBank (the ODFI) and no contractual agreement 
exists between the ODFI and the Originator. In this case, 
ACH Pay Service Provider would have an agreement with 
the ODFI (MegaBank) under which ACH Pay Service 
Provider agrees to be bound to .'the NACHA Operating 
Rules, and ABC Payroll would have agreements with both 
the Originator (the employer) and the other Third-Party 
Sender (ACH Pay Service Provider), under which both 
ABC Payroll and the employer agree to be bound to the 
Rules. 
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C. ORIGINATION OF ACH ENTRIES 

The figures below provide several examples of how 
Third-Party Service Providers can be used in the process 
of originating transactions into the AGH system. 

Example A 

Figure 5 provides an example of how a Third-Party 
Service Provider might be utilized to create the AGH file 
for delivery to the ODFI prior to delivery to the ACH 
Operator. 
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Example B 

Figure 6 provides an example of how a Third-Party 
Service Provider could be utilized to initiate the ACH file 
directly into the ACH Network on behalf of the ODFI. 
The Third-Party Service Provider is acting as the Sending 
Point on behalf of the ODFI. 



Example C 

Figures 7 and 8 provide illustrations of Third-Party 
Senders acting as intermediaries between Originators and 
ODFIs, originating ACH entries on behalf of the 
Originators. 



Third-Party Sender Environment #1 

No agreement in place between Originator and ODFI, but TPS assumes new 
obligations through agreement with ODFI and through agreement with Originator. 
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Third-Party Sender Environment #2 

No agreement in place between Originator and ODFI, but TPS assumes new 
obligations through agreement with ODFI and through agreement with Originator 
and between Third-Party Senders. 
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It is important that all participants in the origination 
process have a clear understanding of their roles and 
responsibilities in processing ACH files when a Third- 
Party Service Provider is utilized to perform an ACH 
processing function. The ODFI must be aware that there 
may not be controls in the ACH Operator software to 
control the dollar value or the type of transaction to be 
originated. Since the ODFI is responsible for the ACH 
entry, direct access to the ACH Network (i.e., as a 
Sending Point) by a Third-Party Service Provider should 
be analyzed very closely by the ODFI. 

The ODFI should ensure that the following issues are 
addressed when either one or both examples are in place: 



OG97 



SECTION IV- SPECIAL TOPICS 

CHAPTER I -THIRD-PARTY SERVICE PROVIDERS 



2005 OPERATING GUIDELINES 




1. AGREEMENTS 

The NACHA Operating Rules require either (1) the 
execution of a contractual agreement between the 
Originator and the ODFI under which the Originator 
agrees to be bound by the Rules and acknowledges that it 
may not initiate entries in violation of the laws of the 
United States, or (2) the execution of appropriate 
agreements (i.e., between ODFIs and Third-Party Senders, 
between Third-Party Senders and Originators, and 
between multiple Third-Party Senders themselves) under 
which the Third-Party Senders agree to be bound by the 
NA CHA Operating Rules and Originators agree to assume 
the responsibilities of Originators under the Rules and 
acknowledge that entries may not be initiated in violation 
of the laws of the United States. 

Third-Party Service Providers 

When agreements have been executed between the 
Originator and the ODFI, it is also recommended that 
agreements be entered into between the Originator and the 
Third-Party Service Provider, and between the Third- 
Party Service Provider and the ODFI. These agreements 
should address responsibilities of each party regarding 
quality of data, input schedules and deadlines, and any 
other issues pertinent to the actual processing and delivery 
of the payment data. 

Example A 

Although agreements have been executed between the 
Originator and the ODFI, the absence of an agreement 
with a Third-Party Service Provider in the role illustrated 
in Example A can add liability to the ODFI, particularly 
if funding arrangements have not been defined. Some 
Third-Party Service Providers actively market ACH 
applications to Originators. The ODFI must ensure that 
there is a process in place for the Third-Party Service 
Provider to inform the ODFI of new Originators in order 
for the ODFI to execute the necessary agreements 
between the ODFI and the Originator(s). 

Example B 

The ODFI must ensure that all agreements with its ACH 
Operator(s) properly identify all Sending Points when the 
ODFI uses the facilities of a Third-Party Service Provider 
as indicated in Example B. 



In addition to the agreements with the ACH Operator(s), 
the ODFI must also ensure that proper agreements are in 
place between the ODFI and all Originators. Once a third 
party is established as a Sending Point for an ODFI, it is 
possible that entries could be initiated into the ACH 
Network for a new Originator without the knowledge of 
the ODFI. The ODFI must establish procedures with its 
Third-Party Service Provider to keep the ODFI informed 
of all ACH activity that is sent into the ACH system. 



Third-Party Senders 

Example C 

In this example, no direct contractual agreement exists 
between the Originator and the ODFI. As a result, the 
ODFI is exposed to an increase in credit risk because it 
has no direct claim against the Originator with respect to 
credit entries originated and for any debit entries returned 
by theRDFI, to the extent that the ODFI does not receive 
payment from the Third-Party Sender. The NACHA 
Operating Rules require appropriate agreements to be 
entered into in which any Third-Party Sender agrees to be 
bound by the NACHA Operating Rules sad Originators 
agree to assume the responsibilities of an Originator under 
the Rules. Such agreements help protect the ODFI against 
credit risk by providing them with the ability to seek 
recovery of payment directly from the Originator. These 
agreements should address the responsibilities of each 
party with respect to financial liability for each 
transaction, the quality of data, input schedules and 
deadlines, and any other issues pertinent to the actual 
processing and delivery of the payment data. 

Issues That Should Be Defined Within an 
QDFI/Third-Party Sender Agreement 

It is recommended that at least the following areas be 
covered in the agreement between the ODFI and Third- 
Party Service Provider/Third-Party Sender. The 
agreement should: 

• provide for established credit limits for batches and 
entire files. A batch or file that exceeds the credit limit 
should be brought to the ODFI's attention before the file 
is deposited so the ODFI can either approve it as an 
exception or ask that it be held until the next day; 



ensure senior management is aware of the practice of 
utilizing a Third-Party Service Provider; 



require that the Third-Party Service Provider not begin 
originating ACH entries for new companies under the 
ODFI's routing number without prior approval from the 
ODFI. The ODFI's approval of each company should 
be contingent upon the creditworthiness of the 
company; 

require that the Third-Party Service Provider notify the 
ODFI of dollar totals for each file the processor 
deposits so that the ODFI can reconcile activity and 
settlement totals on reports from the ACH Operator; 
and 

address who will be responsible for erroneous entries, 
who will handle rejects and in what time frame, who 
will handle returns and notifications of change, how 
customer inquiries will be handled, and what type of 
audit trail will be provided. 
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The ODFI should also request information about the 
processor's financial condition, operating environment, 
what measures the processor has taken to ensure that ACH 
files will be handled accurately and on time, what type of 
physical security the processor has, how the data 
confidentiality is maintained, etc. 

Electronic Records/Record Retention 

Third-Party Service Providers should be aware that the 
NACHA Operating Rules permit ACH participants to 
obtain and store ACH records electronically as an 
alternative to obtaining and retaining such documents in 
hard copy format. Specifically, the Rules allow any 
agreement, authorization, written statement under penalty 
of perjury, or other record required by the NACHA 
Operating Rules to be in writing to be obtained and 
retained in either hard copy or electronic form. 



Electronic Signatures and Records 

Electronic records include agreements, authorizations, 
written statements under penalty of perjury, or other 
records created, generated, sent, communicated, received, 
or stored by electronic means. Electronic records may 
have a signature requirement. 

Electronic signatures are electronic sounds, symbols, or 
processes attached to or logically associated with an 
agreement, authorization, written statement under penalty 
of perjury, or other record executed or adopted by a 
person with the intent to sign the record. These writing 
and signature requirements can be satisfied by compliance 
with the Global and National Commerce Act (E-Sign 
Act). Originators should be aware that any record that is 
signed according to the terms of an applicable state 
version of the Uniform Electronic Transaction Act is 
considered to have been signed in conformance with the 
terms of the E-Sign Act. 

To satisfy the requirements of the NACHA Operating 
Rules (and Regulation E for preauthorized debits), 
electronic signatures must "similarly authenticate" the 
electronic records. The authentication method chosen 
must evidence both the signer's identity and his assent to 
the terms of the record. For purposes of the NACHA 
Operating Rules, ACH records may also be similarly 
authenticated using the same authentication methods 
currently prescribed for consumer debit authorizations - 
that is, the record may be similarly authenticated via the 
Internet through the use of a digital signature, PIN, 
password, shared secret, etc., or a hard copy record may 
be authenticated via the telephone by the consumer's 
speaking or key-entering a code provided on the record. 

Any other written notice or disclosure required by the 
NA CHA Operating Rules but not requiring a signature 
may also be provided in electronic form, including e-mail. 
(This includes the notice for TEL. Please note that state 



and federal laws may require consumer consent before 
using electronic notices/disclosures.) 

Record Retention 

Third-Party Service Providers should be aware that ACH 
participants are permitted to retain copies of ACH records 
in electronic form, provided that the electronic record (1) 
accurately reflects information contained within the 
record, and (2) is capable of being accurately reproduced 
for later reference, whether by transmission, printing, or 
other reproduction. 

Third-parties should be aware that ACH participants 
choosing to utilize electronic communications methods for 
the retention of ACH records should implement practices 
and procedures to ensure that electronic records of ACH 
documents accurately reflect the information contained 
within the document and that both the electronic record 
and a recorded record of the authentication can be 
accurately reproduced for future reference. 

Third-Party Service Providers should be aware that other 
ACH participants may also utilize electronic methods to 
obtain and retain records of ACH documents. In such 
cases, third-parties, on behalf of ACH participants, can 
expect to receive electronic versions, rather than hard 
copies, of documents that they request from other ACH 
participants. 




2. WARRANTIES/INDEMNIFICATIONS 

Even if an ODFI utilizes a Third-Party Service Provider 
in the origination process, the ODFI is responsible for the 
entries that it originates into the ACH system. The ODFI 
warrants that it has entered into an agreement with the 
Third-Parly Service Provider when the third party is used 
to transmit ACH entries directly into the ACH Operator. 

The ODFI also warrants that any Third-Party Service 
Provider that performs a function of ACH processing on 
behalf of the ODFI with regard to entries has conducted 
an annual audit of compliance with the provisions of the 
NACHA Operating Rules. For more information on rules 
compliance audit requirements as they apply to a Third- 
Party Service Provider acting on behalf of an ODFI, refer 
to the Rules Compliance Audit Requirements section 
within this chapter. 

The ODFI's Routing Number appears in the 
Company/Batch Header Record and is repeated in the first 
eight digits of the Trace Number in the Entry Detail 
Record and Addenda Records. The financial institution 
that is represented by that Routing Number is responsible 
for the warranties and indemnifications set forth in 
NACHA Operating Rules . 

Note: It is critical that ODFIs include use of a Third- 
Party Service Provider for origination in their overall 
procedures for analyzing risk and fraud. 



OG99 



SECTION IV -SPECIAL TOPICS 

CHAPTER I -: THIRD-PARTY SER VICE PROVIDERS 



2005 OPERATING GUIDELINES 




The Sending Point can be the ODFI itself or an 
organization other than the ODFI. The Sending Point is 
identified by the Routing Number in the Immediate Origin 
field in the File Header Record. Even if the Routing 
Number in the Immediate Origin field is that of a Third- 
Party Service Provider, it is the financial institution 
represented by the Routing Number in the Originating 
DFI Identification Field that is considered the ODFI. 

3. THIRD-PARTY SENDER OBLIGATIONS 

Each Third-Party Sender is subject to a number of 
additional obligations and liabilities with respect to the 
transmission of ACH entries: 

• Identification of Originators 

Each Third-Party Sender is obligated to provide the 
ODFI with any information that the ODFI considers to 
be reasonably necessary to identify each Originator for 
which the ODFI transmits entries. Upon the receipt of 
a request from the ODFI for such information, the 
Third-Party Sender must provide the requested data to 
the ODFI within two banking, days. 

■• Warranties/Indemnifications of Third-Party Senders 

Each Third-Party Sender that authorizes an ODFI to 
transmit entries to a Receiver's account warrants to the 
ODFI that the Originator has agreed to assume the 
responsibilities of an Originator, as required by the 
NA CHA Operating Rules. In any case in which the 
Originator fails to perform its obligations as an 
Originator under the Rules, the Third-Party Sender 
indemnifies the ODFI against any loss. 

* Assumption of ODFI Warranties 

Each Third-Party Sender assumes the warranties and 
liabilities of an ODFI with respect to: 



the general warranties and liabilities of an ODFI 
under the NACHA Operating Rules (excluding 
those related to Sending Points and Audits); 
Re-presented Check Entries; 
Accounts Receivable Entries; 
Internet-Initiated Entries; and 
ODFI Warranties for Outbound Cross-B order 
Entries. 



Assumption of ODFI Responsibilities 



With respect to the following NA CHA Operating Rules, 
a Third-Party Sender is considered to be a Participating 
DFIorODFI: 

- Compliance With Rules (excluding the sections 
related to Audits, Compensation, Arbitration, and 
Rules Enforcement); 

- Release of Information; and 

- Recall by ODFI or Originator. 

(Note: For a list of these specific subsections within the 
NA CHA Operating Rules, please refer to Article Five, 
Obligations of Third-Party Senders.) 

Assumption of Originator Responsibilities / 



For purposes of the following NACHA Operating Rules, 
each Third-Party Sender is considered to be the 
Originator of an entry with respect to the provision of 
copies of documents to the ODFI: 

- Copy of Item (for RCK entries); 

- Copy of Source Document (for ARC entries); and 

- ' . ■ Record of Authorization. 

(Note: For a list of these specific subsections within the 
NACHA Operating Rules, please refer to Article Five, 
Obligations of Third-Party Senders.) 



(Note: For a list of these specific subsections within the 
NACHA Operating Rules, please refer to Article Five, 
Obligations of Third-Party Senders) 

Payment to ODFI 

Each Third-Party Sender is obligated to make payment 
to the ODFI for all credit entries and for all debit entries 
that are returned by the RDFI. 



4. REVERSALS/ERRONEOUS ENTRIES 

It is critical that responsibility and accountability for 
errors are identified and understood prior to the 
origination of entries. The following issues need to be 
resolved between the ODFI, Originator, and third party: 

• Who is responsible for detecting errors? 
■• Who is responsible for correcting errors? 

•■ In what time frame can errors be corrected? 

• Who will notify the Receiver of a reversing entry 
(e.g., the Originator, or ODFI/Third Party on behalf 
of the Originator)? 

• Who is liable for any claim that may result from an 
error? 

5, THE AUDIT TRAIL 

When a Third-Party Service Provider is utilized, 
procedures must be established for tracing an entry into 
the ACH system. The organization that is the Sending 
Point is usually responsible for being able to provide the 
necessary data that demonstrates delivery to the ACH 
Operator. In addition, some form of audit trail must be 
created in order to track the delivery of information from 
one party to the next until it reaches the Sending Point 
and, subsequently, the ACH Operator. 
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6. RETURNS/NOCS/REJECTED ENTRIES 



Returns, notifications of change, rejected entries, and 
notice of rejected files or rejected batches need to be 
handled expeditiously when they are received by the 
ODFL Part of the process of utilizing a third party to 
originate AGH transactions is the identification of 
responsibilities for handling returns, NOCs, and rejected 
entries. It is the responsibility of the ODFI to determine, 
in its arrangements with Originators and Third-Party 
Service Providers, who is responsible for handling these 
entries appropriately. 

D RECEIVING ACH ENTRIES 

Figures 9 and 10 show how Receiving Depository 
Financial Institutions (RDFIs) can receive entries from the 
ACH Operator. 

Example A 

Figure 9 provides an example of an RDFI that receives 
AGH files directly from the AGH Operator. The RDFI 
acts as its own Receiving Point. 




-> Processing - - - - - - - Agreements 



Figure 9 



Example B 

Figure 10 provides an example of an RDFI that utilizes 
the services of a third party to receive ACH files on its 
behalf. The RDFI's Receiving Point is the third party. 
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The responsibilities of the RDFI in both examples are 
outlined in the RDFIs chapter in Section II of these 
Guidelines; however, this chapter provides additional 
information on areas of importance that should be 
addressed when a third party is used as a Receiving Point, 
as in Example B. 



1. AGREEMENTS 

The RDFI will need to execute the appropriate agreements 
with its ACH Operator in order to have ACH files 
delivered to the proper Receiving Point. The RDFI 
should also enter into an agreement with the Third-Party 
Service Provider. This agreement should define the 
responsibility, accountability, and liability for the 
handling of ACH files. It should also address provisions 
for any additional services the processor may offer to the 
RDFI, such as processing returns, notifications of change, 
etc. (see paragraph 3, Processing Functions, below). 
Third-Party Service Providers should be aware that the 
NA CM A Operating Rules permit RDFIs to obtain and 
retain ACH records electronically. For detailed 
information on electronic records and electronic record 
retention, refer to the section entitled "Origination of 
Entries" within this chapter. 

2. WARRANTIES AND INDEMNIFICATIONS 

The RDFI is responsible for the entries it receives even if 
the RDFI utilizes a Third-Party Service Provider as a 
Receiving Point. The RDFI warrants that any Third-Party 
Service Provider that performs a function of ACH 
processing on behalf of the RDFI with regard to entries 
has conducted an annual audit of compliance with the 
provisions of the NA CHA Operating Rules and is 
otherwise in compliance with the rules compliance audit 
requirements governing the RDFL For more information 
on rules compliance audit requirements as they apply to a 
Third-Party Service Provider acting onbehalf of an RDFI, 
refer to the Rules Compliance Audit Requirements section 
within this chapter. 

The RDFI is identified by the Routing Number in the 
Receiving DFI Identification Field of the Entry Detail 
Record of ACH files. The Receiving Point is identified 
by the Routing Number in the Immediate Destination field 
of the File Header Record. If these two numbers are 
different, the organization represented by the number in 
the Immediate Destination field is the Third-Party Service 
Provider acting as a Receiving Point, and the financial 
institution represented by the number in the Receiving 
DFI Identification field of the Entry Detail Record is the 
RDFL Even if the RDFI is not the Receiving Point, the 
RDFI must ensure that its Receiving Point is processing 
the ACH files in a manner that allows the RDFI to comply 
with iheNACHA Operating Rules: 

3. PROCESSING FUNCTIONS 

The Third-Party Service Provider can provide various 
levels of service to the RDFI, as follows: 




Delivery Only 

An RDFI may choose to use a third party simply to 
receive the ACH file . In this instance, the Receiving Point 
usually is able to receive the file more quickly or more 
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efficiently than the RDFL All ACH Operators require 
electronic delivery to Receiving Points. Using a third 
party with electronic delivery capability would enable the 
RDFI to meet the electronic delivery requirements of its 
ACH Operator. However, RDFIs that use third parties as 
Receiving Points for the electronic delivery of ACH files 
must ensure that subsequent delivery of the information to 
the RDFI is accomplished in such a manner as to ensure 
compliance with the NACHA Operating Rules. For 
example, the RDFI that uses a third party for electronic 
delivery and subsequently receives ACH irrformation from 
that third party via mail or courier will more than likely 
not be able to fulfill the requirements of an RDFI for 
funds availability and for meeting return deadlines. 



Delivery and Processing 




An RDFI may choose to use a third party to receive and 
process its ACH activity. In this instance, the third party 
usually posts the ACH entries to the customers' accounts 
for the RDFI and generates reports to the RDFI indicating 
the functions it has performed. The RDFI must receive 
these activity reports expeditiously in order to fulfill the 
various responsibilities required of an RDFI for 
processing ACH entries, such as reviewing 
prenotifications, initiating returns and notifications of 
change. The Third-Party Service Provider must ensure 
that all of the payment information is passed to the RDFI 
exactly as it was received from the ACH Operator. 

The processing function can also include data retention, 
statement processing, fulfilling disclosure requirements, 
etc. The RDFI should also ensure that its processor is 
recognizing addenda records that accompany ACH entries 
and is processing them according to regulatory 
requirements or the specific requirements of the RDFI or 
the RDFI's account holders. For additional information 
on the processing of addenda records, see Chapter II, 
Addenda Records, in this section. 

Additional Services 

In addition to performing the processing functions for an 
RDFI to properly receive ACH entries, the third party 
may also choose to handle returns and notifications of 
change for the RDFI. This function can be performed 
programmatically, where a return or notification of change 
is automatically generated, or the third party may convert 
paper forms to ACH format. In either case, the third party 
would be performing a function of origination , and the 
RDFI must ensure that the appropriate agreements have 
been completed with the ACH Operator that will enable 
the RDFI to use the Third-Party Service Provider for 
those functions. 

E. RULES COMPLIANCE AUDIT 
REQUIREMENTS 

The NA CHA Operating Rules require any Third-Party 
Service Provider that performs a function of ACH 



processing on behalf of an ODFI or RDFI to conduct an 
annual audit of compliance with the requirements of the 
NA CHA Operating Rules . A function of ACH processing 
includes, but is not limited to, the creation of ACH files or 
acting as a sending or receiving point on behalf of a 
Participating DFL Each annual audit under these rules 
compliance audit provisions must be completed by 
December 1 of that year. Under the NACHA Operating 
Rules, both the ODFI and the RDFI warrant the 
completion of such an audit by these Third-Party Service 
Providers . Both financial institutions and Third-Party 
Service Providers acting on their behalf must retain 
documentation supporting the completion of an audit of 
ACH rules compliance for a period of six years from the 
date of the audit and must provide such documentation to 
the National Association upon request. Third-Party 
Service Providers, as well as the Participating DFIs on 
whose behalf they process, should be aware that such 
documentation will not be asked for in an arbitrary or 
capricious manner; rather, proof of an audit will be 
requested only when deemed reasonably necessary by the 
National Association. Acceptable documentation may 
include, but is not limited to, a letter from an internal, 
outside or independent auditor indicating satisfactory 
performance of all audits. 

Third-Party Service Providers Acting on Behalf of ODFIs 

The NACHA Operating Rules require ODFIs and any 
Third-Party Service Providers performing a function of 
ACH processing on behalf of those ODFIs to perform an 
annual audit that addresses the specific requirements listed 
below. When conducting the annual audit, ODFIs and 
their Third-Party Service Providers must understand that 
these audit provisions do not prescribe a specific 
methodology to be used for the completion of an audit but 
identify key rule provisions that should be examined 
during the audit process. ODFIs and Third-Party Service 
Providers should rely on the guidance of their auditors 
with respect to the specific auditing practices and 
procedures that must be followed. 

• Verify that records of entries, including return and 
adjustment entries, transmitted from or to an ACH 
Operator are retained for six years from the date the 
entry was transmitted. Also verify that a printout or 
reproduction of the information relating to the entry can 
be provided to the Participating DFTs customer or any 
other Participating DFI or ACH Operator that 
originated, transmitted, or received the entry. 

V Verify, when electronic records are used, that such 
records ( 1 ) accurately reflect the information contained 
within the record, and (2) are capable of being 
accurately reproduced for later reference, whether by 
transmission, printing, or otherwise. 

• Ensure that agreements have been made with all 
Originators (corporate customers) or Third-Party 
Senders that bind the Originator or Third-Party Sender 
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to the ACH rules, and that, within such agreements, the 
Originator or Third-Party Sender acknowledges that 
entries may not be initiated that violate the laws of the 
United States. With respect to GBR and PBR entries, 
ODFIs must verify that agreements contain all 
necessary provisions. 

Verify that, if applicable, agreements have been made 
with all Sending Points originating transactions on 
behalf of the ODFL 

Review internal procedures and customer agreements to 
ensure compliance with UCC Article 4A. (Note: This 
review of compliance with UCC 4A is with respect to 
ACH transactions only.) 

Review internal procedures to determine that exposure 
limits are established for each corporate Originator or 
Third-Party Sender, that these procedures provide for 
the exposure limits to be reviewed periodically, and for 
entries initiated by these Originators or Third-Party 
Senders to be monitored relative to the exposure limits 
across multiple settlement dates. 

Ensure that the ODFI has implemented procedures to 
monitor the payments system risk associated with the 
initiation of GBR and PBR entries by each Originator 
or Third-Party Sender. 

For WEB entries, also review internal procedures to 
ensure that the ODFI has established procedures to 
monitor the credit worthiness of each Originator or 
Third-Party Sender on an on-going basis. Also review 
internal procedures to ensure that the ODFI has 
established an exposure limit for each Originator or 
Third-Party Sender, has implemented procedures to 
review that exposure limit periodically, and 
implemented procedures to monitor entries initiated by 
that Originator or Third-Party Sender relative to its 
exposure limit across multiple settlement dates. 

•Review internal procedures to ensure that information 
relating to NOCs and Corrected NOCs is provided to 
each Originator or Third-Party Sender within two 
banking days of the settlement date of the NOC or 
Corrected NOC in accordance with Appendix Six. 

» Review internal procedures to ensure that, when agreed 
to by the ODFI, Permissible Return Entries are 
accepted in accordance with Article Eight, section 8.3 
(ODFI Agrees to Accept CCD or CTX Return). 

» Ensure that Originators and Third-Party Senders are 
kept informed of and are in compliance with their 
obligations on a continuing basis, including 
requirements that: 

- ; the Originator obtain the Receiver's authorization for 
entries, and that copies of such authorizations are 



provided to the Receiver in accordance with the 
requirements of these rules. 

■ if Originators choose to initiate prenotification 
entries, they do so as required by the NACHA 
Operating Rules, 

- entries returned as "R07 - Authorization Revoked by 
Customer," "R08 - Payment Stopped," or ■ "Rl - 
Customer Advises Not Authorized, Notice Not 
Provided, Improper Source Document, or Amount of 
Entry Not Accurately Obtained from Source 
Document" are not reinitiated unless subsequent 
authorization of their customers has been obtained. 

-entries returned for R01 (Insufficient Funds) or R09 
(Uncollected Funds) are not reinitiated in excess of 
the limits prescribed by these rules. 

- upon receipt of returns relating to prenotifications 
indicating that the RDFI cannot accept such entries, 
such entries are not initiated. 

- upon receipt of Notifications of Change, requested 
changes are made within six banking days of receipt 
of the NOC information or prior to initiating the next 
entry to the Receiver's account, whichever is later. 

- reversing files and reversing entries are transmitted to 
the Receiving ACH Operator in such time as to be 
transmitted or made available to the RDFI within five 
banking days following the settlement date of the 
erroneous entry or file. 

- Originators initiating POP entries provide the 
Receiver with a receipt that contains information 
relating to the POP entry, as required by these rules. 

- Originators initiating POP entries void and return to 
the Receiver the source document used for the ACH 
transaction. 

- Originators of WEB entries have employed a 
commercially reasonable fraudulent transaction 
detection system to screen such entries. 

- Originators of WEB entries have used commercially 
reasonable procedures to verify that routing numbers 
are valid. 

- Originators of WEB entries have employed 
commercially reasonable methods of authentication 
to verify the identity of each Receiver. 

- Originators of WEB entries have established a secure 
Internet session with each Receiver utilizing a 
commercially reasonable security technology 
providing a level of security that, at a minimum, is 
equivalent to 1 28-bit RC4 encryption technology 
prior to the Receiver's key entry of any banking 
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information, including, but not limited to, the 
Receiver's routing number, account number, and 
personal identification number (PIN) or other 
identification symbol. 

- Originators of WEB entries conduct annual audits to 
ensure that the financial information they obtain from 
Receivers is protected by security practices and 
procedures that include, at a minimum, adequate 
levels of ( 1 ) physical security to protect against theft, 
tampering, or damage; (2) personnel and access 
controls to protect against unauthorized access and 
use; and (3) network security to ensure secure 
capture, storage, and distribution. 

■■■- Originators initiating entries for which any banking 
information, including, but not limited to, an Entry, 
Entry Data, a routing number, an account number, 
and a PIN or other identification symbol, is 
transmitted or exchanged between a Receiver and an 
Originator, an Originator and an ODFI, or an 
Originator and a Third-Party Service Provider, via an 
Unsecured Electronic Network, have, prior to the key 
entry and through transmission of any banking 
information, (1) encrypted the banking infonnation 
using a commercially reasonable security technology 
that, at a rninimum, is equivalent to 128-bit RC4 
encryption technology, or (2) transmitted or received 
the banking information via a secure session using a 
commercially reasonable security technology that 
provides a level of security that, at a minimum, is 
equivalent to 128-bit RC4 encryption technology. 

Transmissions or exchanges of banking information 
using voice or keypad inputs from a wireline or 
wireless telephone are not subject to this data security 
requirement unless the telephone is used to access the 
Internet. 

- Originators of TEL entries have (1) employed 
commercially reasonable procedures to verify the 
identity of the Receiver, and (2) utilized 
commercially reasonable procedures to verify that 
routing numbers are valid. 

- For ARC and RCK entries, the Originator has 
provided clear and conspicuous notice of the check 
conversion/truncation policy. 

Third-Party Service Providers Acting on Behalf of RDFIs 

The NACHA Operating Rules require all RDFIs and any 
Third-Party Service Providers performing a function of 
ACH processing on behalf of those RDFIs to perform an 
annual audit that addresses the specific requirements listed 
below. When conducting an annual audit, RDFIs and 
their Third-Party Service Providers must understand that 
these audit provisions do not prescribe a specific 
methodology to be used for the completion of an audit but 
identify key rules provisions that should be examined 



during the audit process. RDFIs and their Third-Party 
Service Providers should rely on the guidance of their 
auditors with respect to the specific auditing practices and 
procedures that must be followed. 

■• Verify that records of entries/including return and 
adjustment entries, transmitted from or to an ACH 
Operator are retained for six years from the date the 
entry was transmitted. RDFIs and Third-Party Service 
Providers will also be required to verify that a printout 
or reproduction of the information relating to the entry 
can be provided to the Participating DFFs customer or 
any other Participating DFI or ACH Operator that 
originated, transmitted, or received the entry. 

• Verify, when electronic records are used, that such 
records (1) accurately reflect information contained 
within the record, and (2) are capable of being 
accurately reproduced for later reference, whether by 
transmission, printing, or otherwise. 

• Verify that prenotifications received are for valid 
accounts and that when a prenotification is not 
processable or is erroneous, the prenotification is 
rejected on a timely basis through the use of return 
entry procedures or that changes are requested through 
the Notification of Change procedure. 

• Verify that, subject to the RDFFs right of return, all 
types of ACH entries and prenotifications are accepted. 

• Review records and procedures to ensure that: 

■..- the amount of consumer credit entries is made 
available for withdrawal or cash withdrawal no later 
than the date of settlement, 



for PPD credits, the amount of the PPD credit is 
made available for withdrawal or cash withdrawal at 
the opening of business on Settlement Date whenever 
possible. For PPD credit entries made available to 
the RDFI by 5:00 p.m. (RDFFs local time) on the 
banking day prior to settlement date, funds are made 
available for withdrawal or cash withdrawal no later 
than opening of business on settlement date, RDFIs 
should pick up files that are made available to them 
by their ACH Operators during the afternoon on the 
day before Settlement Date in order to ensure 
compliance with the rules governing funds 
availability for PPD credit entries. 



that debit entries are not posted prior to Settlement 
Date. 



Verify that the RDFI sends or makes available as part 
of the account statement for consumer customers the 
minimum descriptive information concerning each 
credit or debit entry consistent with the requirements of 
Appendix Four (Minimum Description Standards.) For 
ARC, POP, RCK, and XCK entries, verify that the 
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RDFI also provides the contents of the Check Serial 
Number Field on the consumer's statement. Also verify 
that the RDFI sends or makes available/as part of the 
account statement for consumers, the contents of the 
Terminal City Field and Terminal State Field with 
respect to POP entries. 

•■ For all entries except RCK, review records and 
procedures to determine that return entries, including 
rejected prenotifications, are received by the RDFFs 
ACH Operator by its deposit deadline for the return 
entry to be made available to the ODFI no later than the 
opening of business on the second banking day 
following the Setdement Date of the original entry. 
"Second banking day" refers to the second banking day 
of the RDFFs ACH Operator, and "Settlement Date of 
the original entry" refers to the Settlement Date of the 
original entry that is being returned. 

• Review records and procedures to ensure that 
dishonored return entries received by the RDFI are 
handled appropriately, and that contested dishonored 
return entries and corrected returns are initiated in a 
timely manner. 

• Review internal procedures and customer agreements to 
ensure compliance with UCC Article 4A. (Note: This 
requirement is with respect to ACH transactions only.) 

• Review records and procedures to ensure that written 
statements under penalty of perjury are obtained from 
consumers for all returns bearing Return Reason Codes 
R07, RIO, R37, R51, andR53, and that each adjustment 
entry is received by the RDFFs ACH Operator by its 
deposit deadline for the adjustment entry to be made 
available to the ODFI no later than the opening of 
business on the banking day following the sixtieth 
calendar day following the settlement date of the 
original entry. Verify that copies of written statements 
under penalty of perjury are provided to the ODFI 
within the required time frame, when such copies are 
requested by the ODFI in writing. 

• Verify that, with the exception of NOCs due to merger 
or acquisition, Notifications of Change are transmitted 
within two banking days of the settlement date of the 
entry to which the NOC relates. 

• Review records and procedures to ensure that, when 
requested to do so by the Receiver, the RDFI provides 
all payment-related information transmitted with CCD, 
CIE, and CTX entries to the Receiver by the opening of 
business on the second banking day following the 
settlement date of the entry. 

• Review internal procedures to ensure that the return of 
an RCK entry is transmitted to the RDFFs ACH 
Operator by midnight of the second banking day 
following the banking day of receipt of the presentment 
notice. 



• Review internal procedures to ensure that, for each 
RCK entry for which a stop payment has been placed 
on the item to which the RCK entry relates and for each 
ARC entry for which a stop payment order has been 
placed on the source document to which the ARC entry 
relates, the adjustment entry is received by the RDFFs 
ACH Operator by its deposit deadline for the 
adjustment entry to be made available to the ODFI no 
later than the opening of business on the banking day 
following the sixtieth calendar day following the 
settlement date of the original entry. (Note: No written 
statement under penalty of perjury is required for 
entries returned for these reasons.) 

* Review internal procedures to verify that, for consumer 
entries except ARC, POP, RCK, TEL, and Single-Entry 
WEB entries, the RDFI has acted on stop payment 
orders placed with the RDFI at least three banking days 
prior to the scheduled date of the transfer. For 
corporate entries, as well as for ARC, POP, RCK, TEL, 
and Single-Entry WEB entries, verify that the RDFI has 
acted on stop payment orders that have been received in 
such time and in such manner that allow the RDFI to act 
on the stop payment order prior to acting on the debit 
entry. 

F. SUMMARY .,..::..:;..;. 

Use of a Third-Party Service Provider can greatly enhance 
the origination and receiving capabilities of the ODFI and 
RDFI. It is important that both the ODFI and the RDFI 
are aware of their responsibilities in ACH processing and 
ensure that those responsibilities are being met even if a 
third party is performing the processing function. Use of 
a Third-Party Service Provider does not relieve the ODFI 
or RDFI from its obligation to understand and comply 
with the NACHA Operating Rules. 



SECTION IV 
SPECIAL TOPICS 

CHAPTER!! 
ADDENDA RECORDS 

A/ INTRODUCTION 

This section is designed to assist in the implementation of 
payment formats accompanied .by addenda records 
utilizing ASC XI2 standards and NACHA endorsed 
banking conventions. The American National Standards 
Institute (ANSI) Accredited Standards Committee (ASC) 
X12 Interchange Control Structure (ANSI ASC X12.5), 
Application Control Structure (ANSI ASC X12.6), 
transaction sets containing a BPR or BPS data segment 
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(the 52 1 Transaction Set, the 8 1 3 Transaction Set, the 820 
Transaction Set, the 823 Transaction Set, and the 835 
Transaction Set), and UN/EDIFACT payment related 
syntax are referenced but are not included in this section. 
In addition, the NA CHA Operating Rules does not specify 
which version of the standards is to be used. However, 
the examples, definitions, and ASC X12 standards 
discussed in this chapter are derived from the version 
release 3020 of the ASC X 1 2 Standards manual. To 
receive additional information about ASC X12 or 
UN/EDIFACT payment related syntax, please contact the 
Data Interchange Standards Association (DISA) at 7600 
Leesburg Pike, Suite 430, Falls Church, VA 22043, 
703/548-7005. To obtain a copy of the X12 Standards, 
contact: EDI Support Services, Inc., P.O. Box 203, 
Chardon, OH 44024, 800/334-4912. To receive 
information on NACHA endorsed banking conventions, 
please contact NACHA at 13665 Dulles Technology 
Drive, Suite 300, Herndon, VA 20171, 703/561-1 100. 

NACHA has developed several payment formats that may 
be accompanied by addenda records utilizing payment 
related ANSI ASC X12 transaction sets and data 
segments: PPD, CCD, and CTX. The standards for these 
transaction sets (currently, the Income or Asset Offset 
[known as the 521 Transaction Set], the Electronic Filing 
of Tax Return Data [known as the 813 Transaction Set], 
the Payment Order/Remittance Advice [known as the 820 
Transaction Set], Lockbox [known as the 823 Transaction 
Set], and the Health Care Claim Payment/Advice [the 835 
Transaction Set],) were developed by the ASC X12, a 
standards development committee formally chartered by 
ANSI. The ASC X12 Committee consists of 
corporations, financial institutions, trade associations, 
government agencies, and other organizations interested 
in the development and increased use of Electronic Data 
Interchange (EDI), the exchange of business transaction 
information in machine readable format. 

In addition to carrying payment related ANSI ASC X12 
data segments, the CCD and PPD payment formats may 
carry NACHA-endorsed banking conventions. 

B. CORPORATE PAYMENTS 

This section of the NACHA Operating Guidelines 
explores the two corporate ACH formats which may 
utilize ASC X12 standards in the Type "05" addenda 
record: 

1. THE CASH CONCENTRATION OR 
DISBURSEMENT ENTRY WITH AN 
ADDENDA RECORD, OR "CCD-PLUS" 

A CCD may relay information in the "05" addenda using 
payment related ANSI ASC XI 2 data segments (currently 
from the 52 1 Transaction Set, the 8 13 Transaction Set, the 
820 Transaction Set, the 823 Transaction Set, or the 835 
Transaction Set) or a NACHA endorsed banking 



convention. Data segments from other standards are not 
permitted in the addenda record. 

Preparing the CCD Addenda Record 

For CCD entries, only one addenda record may 
accompany each entry. The addenda record includes 80 
characters of payment related information. Users of this 
payment format may insert any combination of payment 
related ANSI ASC X12 data segments and data elements 
(i.e., any combination of data segments and data elements 
from the 521 Transaction Set, any combination of data 
segments and data elements from the 8 1 3 Transaction Set, 
any combination of data segments and data elements from 
the 820 Transaction Set, any combination of data 
segments and data elements from the 823 Transaction Set, 
or any combination of data segments and data elements 
from the 835 Transaction Set) or any NACHA endorsed 
banking conventions, utilizing up to 80 characters. 

For CCD entries with an addenda record, the NA CHA 
Operating Rules have designated the "*"■ (asterisk) as the 
convention for the data element separator, referred to as 
the "delimiter," and the "\" (backslash) as the convention 
for the end of segment indicator, referred to as the 
"terminator." 

2. THE CORPORATE TRADE EXCHANGE 
(CTX) FORMAT 

A CTX relays information using the ASC X12 
Interchange Control Structure, Application Control 
Structure, ANSI ASC X12 transaction sets containing a 
BPR or BPS data segment (i.e., 521 Transaction Set, 813 
Transaction Set, 820 Transaction Set, 823 Transaction 
Set, or 835 Transaction Set), or payment related 
UN/EDIFACT syntax. The addition of one or more 
addenda records to the entry detail record allows a 
corporation to transmit payment related information. The 
presence of an addenda record is not mandatory with CTX 
entries. 

• For CTX entries there is. a limit of 9,999 addenda per 
ACH payment. 

• Only the ASC X12 Interchange Control Structure 
(ANSI ASC X12.5), Application Control Structure 
(ANSI ASC X12.6), ANSI ASC X12 transaction sets 
containing a BPR or BPS data segment (i.e., 521 
Transaction Set, 813 Transaction Set, 820 Transaction 
Set, 823 Transaction Set, or 835 Transaction Set), or 
payment related UN/EDIFACT information are allowed 
in the CTX addenda record. 

• For CTX entries which use multiple addenda, the 
addenda are, in effect, chained together with each 
succeeding addenda record carrying the next 80 
characters of the message. 
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• : An addenda sequence number is provided in the 
addenda record. The sequence number is "0001" for 
the first addenda record. Each succeeding addenda 
must contain a number greater than the previous 
addenda. 

° Standards developed by the ASC X12 are developed for 
computer processing and are not easily readable by 
human operators, since codes are often used to relay 
information. 

• The format of the ASC X12 message within the 
addenda records is referred to as "enveloping" since it 
is analogous to placing a message within an envelope 
and attaching it to a payment as it flows through the 
system. 

Corporate payments may carry a dollar value or a zero 
dollar value. In the case of a dollar value entry, a dollar 
amount greater than zero is sent with the remittance detail. 
In the case of a zero dollar value entry, an amount of zero 
is placed in the amount field of the entry indicating that 
the value of the transaction is zero; however, remittance 
information is carried in the addenda to support the zero 
dollar payment. Zero dollar payments with remittance can 
be treated similarly to dollar payments in that they can be 
coded as debits or credits to savings or demand accounts. 
Typically, zero dollar payments are embedded in an 
ongoing application where the transactions usually have 
value; however, for a particular time period, such as in the 
tax or health care industries, no funds are owed. Zero 
dollar transactions can also be sent through the ACH as a 
pre-advice, where remittance detail is sent from the 
Originator to the Receiver prior to the actual payment. 
This process allows any problems with the remittance 
detail to be worked out prior to the flow of funds. A zero 
dollar transaction can be sent with a CCD+ and CTX 
entry. 

The X12 message consists of three envelopes outside of 
the detailed data segments. 

■'• ISA/IEA 

The outermost envelope is an "Interchange Control" 
Envelope which consists of an Interchange Control 
Header (ISA) and an Interchange Control Trailer (IEA). 
The ISA/IEA Interchange Segments are used to identify 
the Originator and the receiver of a physical 
transmission (point-to-point) . The structure of this 
envelope is defined by the ASC X12 Interchange 
Control Structures. 

•GS/GE 

Within the ISA/IEA envelope is a "Functional Group" 
Envelope with a Functional Group Header (GS) and a 
Functional Group Trailer (GE). The identifications 
used in the GS/GE envelope are different from those in 
the ISA/IEA in that they identify the point of 



application at both the originating and receiving 
companies. The structure of this envelope is defined by 
the ASC X12 Application Control Structure. 
Collectively, the headers and trailers of these two 
segments allow data to be segregated logically for easy 
interpretation by the receiver. 

• ST/SE (ANSI ASC X12 transaction sets containing a 
BPR or BPS data segment [i.e., 521, 813, 820, 823, or 
835 Transaction Sets], and Payment Related 
UN/EDIFACT Standards) 

The innermost envelope is the "transaction set" which 
begins with the Transaction Set Header (ST) and ends 
with the Transaction Set Trailer (SE). The transaction 
set structure is defined by an ANSI ASC X12 
transaction set containing a BPR or BPS data segment 
(i.e., 521 Transaction Set, 813 Transaction Set, 820 
Transaction Set, 823 Transaction Set, or 835 
Transaction Set), or payment related UN/EDIFACT 
syntax. The 820 Transaction Set, the 835 Transaction 
Set, and the 8 1 3 Transaction Set contain detailed data 
segments which are used to define purchase order and 
remittance advice information, explanation of benefits 
(EOB) remittance advice information, and electronic 
tax filing remittance information, respectively. The 52 1 
Transaction Set is used for income or asset offsets, and 
the 823 Transaction Set accommodates lockbox 
processing. 

With CTX entries, each of the three envelopes may only 
be used once. Although ASC X12 does allow multiple 
Functional Envelopes within the Interchange Envelope 
and multiple like-Transaction Sets within a Functional 
Envelope, the NACHA Operating Rules allow only one 
such envelope per CTX entry. (This limitation applies to 
the ISA/IEA, GS/GE and ST/SE envelopes.) 

Preparing the CTX Addenda Record(s) 

Preparing a CTX entry requires the preparation of a file of 
ASC X 1 2 formatted information. The NACHA Operating 
Rules specifically require a CTX entry to follow the 
prescribed syntax of the ASC XI 2 Interchange Control 
Structures (ANSI ASC X12.5), Application Control 
Structure (ANSI ASC X12.6), and ANSI ASC X12 
transactions containing a BPR or BPS data segment (i.e., 
521 Transaction Set, 813 Transaction Set, 820 
Transaction Set, 823 Transaction Set, or 835 Transaction 
Set) or payment related UN/EDIFACT standards. In 
accordance with the agreement that the Originator has 
with its financial institution (the ODFI), the Originator 
may either prepare the CTX entries or pass the X 1 2 
information to its financial institution to prepare the ACH 
file. Any editing or formatting of transaction information 
done by the ODFI can be considered a value-added 
service performed by that organization. 

CTX entries may be produced by scanning the 
information in the ASC X12 message. From the 




OG 107 



SECTION IV- 

CHAPTER II- 



SPECIAL TOPICS 
ADDENDA RECORDS 



2005 OPERATING GUIDELINES 




information contained in the data segments, the NACHA 
record formats can be constructed. 

Compression of the Data 

Once the record formats are constructed, the X12 message 
is then divided into 80-character segments and inserted 
within the addenda records. The Payment Related area of 
the addenda should be fully utilized by "compressing" the 
ASC X12 data. Compression is a procedure in which one 
segment immediately follows the preceding segment If 
a data segment is longer than eighty characters, the 
payment related field of the first addenda record is 
completely filled and the data is "wrapped" to the 
payment related field in the next addenda record. 
(Fourteen characters of the addenda record contain the 
tracking and control information needed for ACH 
processing.) A maximum of 9,999 addenda records may 
be generated for any one CTX message, allowing a 
message totaling nearly 800,000 bytes. 

Delimiters, Terminators, and Version Release 

For CTX payments, the ASC X12 structure allows the 
originator flexibility in selecting delimiters, terminators, 
and the Version Release Control Number. The value of 
these elements will be defined in the ISA segment and will 
be chosen by agreement between the Originator and 
Receiver. Corporate users should note that delimiters and 
terminators must be contained in the NACHA data 
character set (EBCDIC characters with a value greater 
than hexadecimal "3F" and ASCII characters with a value 
greater than hexadecimal " IF"). Communication control 
characters, those characters with a EBCDIC value of "3F" 
or less or an ASCII value of "IF" or less, interfere with 
the processing systems of ACH Operators and RDFIs and 
cannot be used. 

By combining payments with EDI payment information, 
corporations enjoy many benefits. The combination of 
payment and payment information allows the corporation 
to apply this information in an automated manner upon 
receipt rather than manually reconciling the data and 
dollars. In general, EDI provides a basis for complete 
end-to-end automation of order entry information. 

C. RBFI OUTPUT 

The NACHA Operating Rules require that, upon the 
request of the Receiver, an RDFI must provide to each 
Receiver all payment-related information contained within 
the addenda records transmitted with CCD, CTX, and CIE 
entries. RDFIs must have procedures in place to respond 
to requests from Receivers that desire to receive payment- 
related information transmitted with these entries . RDFIs 
must provide the Receiver with the requested information 
by the opening of business on the second banking day 
following the settlement date of the entry to which the 
payment-related information relates. The requirement that 
an RDFI provide payment-related information contained 



within the addenda records of CCD, CTX, and CIE entries 
applies to those payments received after the request is 
made by the Receiver. The provision of payment-related 
addenda record information relating to payments received 
prior to the Receiver's request is at the discretion of the 
RDFI. 

The method by which the payment-related information is 
provided to the Receiver is not prescribed by the NACHA 
Operating Rules. Instead, the medium to be used is to be 
determined by the RDFI and the Receiver. RDFIs are 
encouraged, in conjunction with their customers, to 
determine the method by which the addenda record 
information will be provided, i.e., either in human- 
readable or machine-readable format. If the addenda 
record information will be provided in human-readable 
format, the RDFI must ensure that the addenda 
information is translated from ANSI ASC X12 syntax or 
a NACHA-endorsed banking convention and provided to 
the Receiver in human-readable text. If the addenda 
record information will be provided in machine-readable, 
electronic file format (i.e., computer-to-computer data 
transmission), the RDFI and Receiver will need to 
determine whether the information will be (1) transmitted 
to the Receiver as a pass-through of the electronic file 
format (i.e., 521, 813, 820, 823, 835), (2) translated into 
a proprietary format agreed to by the RDFI and Receiver, 
or (3) merged with the Receiver's lockbox data. 

RDFIs should take care to ensure that zero dollar 
payments with remittance data are handled in the same 
manner as payments that have a dollar value. 

For return items, the RDFI should return an item as it 
normally does for any payment which carries addenda 
information. The entry detail is returned, but only one 
addenda which supplies the reason for the return and other 
data as specified in the NACHA Operating Rules is used. 
The addenda records with the ASC X12 information are 
not returned. 

D. CONSUMER PAYMENTS 

Prearranged Payment or Deposit (PPD) 

The Prearranged Payment or Deposit (PPD) format is a 
consumer payment format which allows the debiting or 
crediting of a consumer's account by an Originator or 
financial institution. The PPD entry may be accompanied 
by one addenda record (Addenda Type "05") carrying 
payment related ANSI ASC X12 data segments (i.e., from 
the 521 Transaction Set, 813 Transaction Set, 820 
Transaction Set, 823 Transaction Set, or 835 Transaction 
Set) or NACHA endorsed banking conventions to 
transport limited financial information. 

Preparing the PPD Addenda Record 



For PPD entries, only one addenda record may 
accompany each entry. The addenda record includes 80 
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characters of payment related information. Users of this 
payment format may insert any combination of payment 
related ANSI ASC X12 data segments and data elements 
(i.e., any combination of data segments and data elements 
from the 521 Transaction Set, any combination of data 
segments and data elements from the 813 Transaction Set, 
any combination of data segments and data elements from 
the 820 Transaction Set, any combination of data 
segments and data elements from the 823 Transaction Set, 
or any combination of data segments and data elements 
from the 835 Transaction Set) or any NACHA endorsed 
banking conventions, utilizing up to 80 characters. 

For PPD entries with an addenda record, the NACHA 
Operating Rules designate the "*" (asterisk) as the 
convention for the data element separator, referred to as 
the "delimiter," and the "\" (backslash) as the convention 
for the end of segment indicator, referred to as the 
"terminator." 

E. OTHER APPLICATIONS 

Automated Enrollment (ENR) 

The Automated Enrollment (ENR) format allows account 
holders (both consumers and companies) to request their 
depository financial institutions to forward, via the AGH 
Network, enrollment information for future ACH credit 
and debit applications to Federal Government Agencies 
that have chosen to utilize the Automated Enrollment 
process. The ENR entry may be accompanied by up to 
9,999 addenda records, depending upon the number of 
enrollments being sent to the same Federal Agency by the 
DEL Addenda records transmitted with an ENR entry 
must contain the NACHA endorsed banking convention 
specified in the NACHA Operating Rules . 

Preparing th e ENR A ddenda Record 

Each ENR entry may contain up to 9,999 addenda 
records. All addenda records must pertain to 
enrollments being sent to the same participating 
Federal Government Agency identified within the 
Entry Detail Record of the ENR. Each addenda record 
includes 80 characters of payment related information 
used to transmit one ACH enrollment. A separate 
addenda record should be used for each additional 
enrollment. Users of the ENR must adhere to the 
NACHA endorsed banking convention specified in the 
NACHA Operating Rules when preparing this portion of 
the addenda record. 

For ENR entries, the NACHA Operating Rules designate 
the ."*" (asterisk) as the convention for the data element 
separator, referred to as the "delimiter," and the "\" 
(backslash) as the convention for the end of the segment 
indicator, referred to as the "terminator." 



F. BASIC ASC X12 RULES 

Figure 11 illustrates the structure of an ASC X 1 2 
transaction. Of principal interest is the transaction set 
envelope of the message which carries the detailed data 
segments of the payment-related ANSI ASC X12 
transaction set (i.e., Income or Asset Offset, Electronic 
Filing of Tax Return Data, Payment Order/Remittance 
Advice, Lockbox, or Health Care Claim 
Payment/Advice). The transaction set envelope consists 
of three areas: 

• the header area: 



the detail area; and 
the summary area. 



Each of the three areas of the transaction set (820, 835, or 
813) consists of data segments which may be mandatory 
or optional. Data segments are made up of smaller 
components called data elements, which may be 
mandatory, optional, or relational. Data elements are 
fixed or variable length; minimum and maximum values 
are provided for variable-length elements. 

NOTE : The diagram in Figure 1 1 illustrates the structure 
of an X12 message containing multiple Functional 
Envelopes within the interchange Envelope and multiple 
like-Transaction Sets within a Functional Envelope. 
Although ASC X12 allows mis structure, the NACHA 
Operating Rules allow only one such envelope per CTX 
entry. (This limitation applies to the ISA/IEA, GS/GE 
and ST/SE segments.) 

1. XI 2 Data Segment Requirement 

Data segments within the Interchange Control Structures, 
the Application Control Structure, and the ANSI ASC 
XI 2 transactions sets containing a BPR or BPS data 
segment (the 521 Transaction Set, the 813 Transaction 
Set, the 820 Transaction Set, the 823 Transaction Set, or 
the 835 Transaction Set) will have one of the following 
two designators which define their requirement: 

a. Mandatory (M) - This data segment must be present 
in the transaction set. 

b. Optional (O) - The appearance of this segment in the 
transaction set is either at the option of the sending 
party or is based on the mutual agreement of the 
interchange parties. 

2. Data Element Requirement 

Data elements within a particular data segment will have 
one of the following three types of designators which 
define their requirement within that segment: 
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a. Mandatory (M) - The data element must be present in 
the segment (presence means a data element must not 
be empty). 

b. Optional (O) - This element may or may not be used, 
depending on the requirements of the Originator. 
Optional fields not used will be flagged by an"*". 

c. Relational (X) - Relational conditions may exist 
among two or more data elements within the same 
data segment based on the presence or absence of one 
of those elements. 

3. Data Element Types 

Data element types are described as follows: 

• DT-Date 

A date data element is used to express the ISO 
standard date in YYMMDD format in which YY is 
the year in the century (00 to 99), MM is the month 
(0 1 to 1 2), and DD is the day in the month (01 to 31). 

e R - Decimal Number 

A decimal data element contains an explicit decimal 
point and is used for numeric values that have a 
varying number of decimal positions. The decimal 
point always appears in the character stream if the 
decimal point is. at any place other than the right end. 
If the value is an integer (decimal point at the right 
end), the decimal point should be omitted. For 
negative values, the leading minus sign (-) is used. 
Absence of a sign indicates a positive value. The 
plus sign (+) should not be transmitted. Leading 
zeros should be suppressed unless necessary to 
satisfy a minimum length requirement. Trailing zeros 
following the decimal point should be suppressed 
unless necessary to indicate precision. The use of 
triad separators (for example, the commas in 
1,000,000) is expressly prohibited. The length of a 
decimal type data element does not include the 
optional leading sign or decimal point 



/^Communications Transport Protocol 
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Control Header 
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Figure 1 1 



The following is an example of a $100.00 positive 
integer value in the BPR data segment for the 
"Monetary Amount" data element (variable length of 
one to fifteen characters): 



MOO 1 * 



The next example illustrates a $ 1 00.02 fractional value 
in the same data segment and data element: 



400.02* 



ID - Identifier 



An identifier data element always contains a value 
from a predefined list of values that is maintained by 
the XI 2 Gornmittee or some other body recognized 
by the X12 Committee. Trailing spaces should be 
suppressed unless necessary to satisfy minimum 
length. 

•■ Nn- Numeric 



A numeric data element is represented by one or 
more digits with an optional leading sign representing 
a value in the normal base 10. The value of a 
numeric data element includes an implied decimal 
point. It is used when the position of the decimal 
point within the data is permanently fixed and is not 
to be transmitted with the data. The data element 
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dictionary defines the number of implied decimal 
positions. The representation for this data element 
type is Nn where N indicates that it is numeric and n 
indicates the number of decimal positions to the right 
of the fixed implied decimal point. For negative 
values, the leading minus sign (-) is used. Absence of 
a sign indicates a positive value. The plus sign (+) 
should not be transmitted. Leading zeros should be 
suppressed unless necessary to satisfy aminimum 
length requirement. The length of a numeric type 
data element does not include the optional sign. 



AN -String 



A string data element is a sequence of any characters. 
The characters shall be left justified and shall be 
space filled. Leading spaces, when they occur, are 
presumed to be significant characters. Trailing 
spaces should be suppressed unless they are 
necessary to satisfy minimum length. 

« TM-Time 

A time data element is used to express the ISO 
standard time in HHMMSSd..d format in which HH 
is the hour for a 24 hour clock (00 to 23), MM is the 
minutes (00 to 59), SS is the seconds (00 to 59), and 
d..d is decimal seconds. 

After the Originator has provided all of the elements 
needed in a segment, the segment can be terminated. 
For example, the following is a remittance segment 
relating to an invoice, number 022. The total amount 
of the invoice is $2,000.00. 

RMR*IV*022**2000.00\ 

The following is the actual RMR Segment to which 
the example can be compared: 

RMR*Reference Number Qualifier ^Reference 
Number*Payment Action Code*Monetary 
Amount*Total Invoice Credit/Debit 
Amount*Discount Amount TakenV 

NOTE : The addition of the second asterisk showing 
the omission of the Payment Action Code element 
(482) demonstrates an optional field not used. Rather 
than indicating the omission of the elements 
following the Monetaiy Amount (782), or $2,000, the 
segment is terminated using a backslash. 

One use of CTX is for the RDFI to send the receiving 
corporation pure X12 information that has been stripped 
from the CTX addenda records. This requires less time 
and effort than reformatting the information into another 
industry standard. To retrieve the pure X 1 2 message from 
the CTX transaction, the RDFI will need to: 



• insert the Settlement Date in the DTM segment 
(translating the Julian date in the ACH batch header to 
a YYMMDD format); 

• detach the addenda from the entry detail record; and 

> strip away the ACH addenda record type code, the 
addenda type code, addenda sequence number, and the 
entry detail sequence number. 

For CCD and PPD entries with an addenda record, the 
payment related ANSI ASC 'XI 2 data segment (i.e., the 
521 Transaction Set, the 813 Transaction Set, the 820 
Transaction Set, the 823 Transaction Set, or the 835 
Transaction Set data segment) may only be used once per 
addenda record — for payments with multiple remittance 
documents, the CTX format must be used. Even though 
the information carried with the CCD payment is limited 
to 80 characters, RDFIs may wish to assist their customers 
by interpreting the information. The receiving 
corporations may not have systems designed to interpret 
X12 iriformation. The segments most widely used with 
this transaction will be the REF, RMR, NTE, and DTM 
data segments orNACHA endorsed banking conventions. 

NOTE : For CCD payments, the following payment 
related ANSI ASC X12 data segments (i.e., from the ASC 
X12 521 Transaction Set, 813 Transaction Set, 820 
Transaction Set, 823 Transaction Set, or 835 Transaction 
Set) will not be used in the addenda record: 

ST (Transaction Set Header) 

BPR (Beginning Segment Payment 

Order/Remittance Advice) 
CUR (Currency) 
SE (Transaction Set Trailer) 



Figure 12 below explains the components of a segment 
and an element. 

G. SEGMENT DIAGRAM KEY 




The following diagram illustrates how a data segment 
provides references to codes and terms used in the ASC 
X12 standards. (Note that the actual interchange of 
information does not include all the reference characters 
shown in the diagram. Only the data segment identifier 
characters, the values for each data element, the data 
element separator, and the data segment terminator 
characters are actually transmitted.) 
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Oats/Time 
Qualifier 



373 DTM03 337 DTM04 623 DTM05 624 



Time 
Code 



Figure 12 



AN = String 
DT = Date 
TM-Time 



* 9, Data Element Length - The minimum and maximum 
length of the data element. The length of the data 
element value is the number of character positions 
used except as noted for numeric and decimal 
elements. 

The format for ACH addenda records was developed to 
provide up to 80 characters of payment-related 
information. For CCD and PPD entries, there is a limit of 
one addenda record per transaction. 




1. Segment Identifier - A unique combination of two 
or three letters or digits used to identify the segment. 



2. 



3. 



4. 



Data Element Reference Designator - The 

structured code assigned to a data element to indicate 
the segment in which it is used and its sequential 
position within that segment. This code is made up 
of the Segment Identifier followed by a two digit 
sequence number. 

Data Element Reference Number - A unique 
reference number used to locate the data element 
definition and specifications in the Data Element 
Dictionary (standard where the contents of all data 
elements are defined). 

Data Element Separator - The character selected by 
the sender which precedes every data element, 
whether the data element is used or not. The data 
element separator must be different from the segment 
terminator and, once selected, must not appear in a 
data element value. 



5. Data Element Name - The name of the data element. 

6. Segment Terminator - The character selected by 
sender to end each data segment. The segment 
terminator must be different from the data element 
separator and, once selected, must not appear in a 
data element value. (For CCD and PPD payments 
with addenda, this will always be a backslash.) 

7. Data Element Requirement Designator - Defines 
the circumstances under which a data element must 
be present or not present in a particular data segment. 
The Data Element Requirement Designators are: 
mandatory, optional, or relational. 

8. Data Element Type - Describes the characters that 
may be used. 

N = Numeric 
R = Decimal 
ID = Identifier 



SECTION IV 
SPECIAL TOPICS 

CHAPTERIII 
OFAC COMPLIANCE 

A. INTRODUCTION 



The U.S. Treasury Department's Office of Foreign Assets 
Control ("OFAC") administers economic sanctions and 
embargo programs that require assets and transactions 
involving interests of target countries, target country 
nationals, and other specifically identified companies and 
individuals be frozen. For purposes of OFAC 
compliance, these entities are referred to as "Specially 
Designated Nationals and Blocked Persons." OFAC 
maintains and regularly updates a master list ("SDN List") 
identifying known "blocked parties." 

All of the sanctions programs enforced by OFAC involve 
declarations of national emergency by the President of the 
United States, As with all payment mechanisms, the ACH 
Network is subject to the requirement to comply with 
OF AC-enforced sanctions policies. 

■B. SCOPE OF COVERAGE 

All U.S. citizens and permanent resident aliens, 
companies located in the U.S., overseas branches of U.S. 
companies, and, in some cases, overseas subsidiaries of 
U.S. companies fall under OFAC jurisdiction. In terms of 
the ACH Network, this means that all U.S. ACH 
participants, including Originators, Originating 
Depository Financial Institutions (ODFIs), Receiving 
Depository Financial Institutions (RDFIs), Receivers and 
Third-Party Service Providers need to be aware that they 
can be held accountable for sanctions violations by the 
U.S. Government and must understand their compliance 
obligations. 
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C. IMPACT TO THE ACH NETWORK 

In September 1997, the NACHA Operating Rules were 
amended to require that Originator/ODFI agreements 
include an acknowledgment by the Originator that ACE 
transactions it originates comply with the laws of the 
United States. This amendment places financial 
institution liability for the inadvertent processing of a 
domestic ACH transaction in violation of OFAC-enforced 
sanctions policies on the financial institution holding the 
account of the blocked party. 

D. INTERNATIONAL ACH TRANSACTIONS 



For purposes of this discussion, an international ACH 
transaction is an ACH transaction for which (1) at least 
one financial institution or Third-Party Service Provider 
involved in the transaction is domiciled in the U.S. or is 
otherwise under U.S. jurisdiction, and at least one party to 
the transaction is outside U.S. jurisdiction; or (2) most or 
all parties to the transaction are outside the U.S., but at 
least one financial institution involved in the transaction 
is subject to U.S. jurisdiction (e.g., a foreign branch of a 
U.S.bank). 

For example, international AGH transactions can include 
an ACH transaction where both the ODFI and RDFI are 
domestic institutions, but the transaction is initiated via a 
S.W.I.F.T. instruction received from a foreign party. 

With respect to international ACH transactions, 
NACHA' s understanding regarding domestic financial 
institution liability being limited to the institution holding 
the blocked account may not apply under U.S. sanctions 
policies. This is due to a number of factors, including (1) 
the lack of U.S. jurisdiction over one or more parties to 
the transaction, and (2) an increase in exposure to 
transactions involving foreign accounts, which have 
greater potential to violate OF AC sanctions since most 
(but not all) blocked parties on the SDN List and their 
accounts reside outside the U.S. 

E. OBLIGATIONS OF ORIGINATORS 

Originators of domestic ACH transactions should be 
aware that they are subject to applicable U.S. law, 
including OFAC-enforced sanctions, when initiating ACH 
entries. Originators of international ACH transactions 
that initiate through an ODFI that is under U.S. 
jurisdiction similarly must be aware that their ODFI is 
subject to OFAC-enforced sanctions. 

Originators in either category should not be acting on 
behalf of, or transmitting funds to or from, any blocked 
party subject to OFAC-enforced sanctions. Agreements 
between ODFIs and Originators should include a 
statement that the Originator acknowledges that it may not 
initiate entries that violate the laws of the United States. 
Originators should be aware that they will be held to an 
obligation to originate only lawful ACH entries under 



such agreements with their ODFIs. Originators of ACH 
transactions should also be aware that their ODFI may, 
from time to time, need to temporarily suspend processing 
of a transaction (particularly an international ACH 
transaction) for greater scrutiny, which might result in 
delayed settlement and/or availability of entries. 

F, OBLIGATIONS OF ODFIs 

ODFIs that choose to originate ACH entries on behalf of 
their customers should be aware that both they and their 
Originators are subject to the NACHA Operating Rules 
and applicable U.S. law when transmitting these entries. 
ODFIs should make this obligation clear in their 
agreements with Originators. ODFIs processing 
international ACH transactions may also find it beneficial 
to include in their agreements a reference to possible 
delays in processing, settlement and/or availability of 
these transactions where enhanced scrutiny may be 
necessary. 

The NACHA Operating Rules reflect the "Know Your 
Customer" principle that the ODFI will verify the 
Originator is not a blocked party and that a good faith 
effort will be undertaken to determine, through the normal 
course of business, that the Originator is not engaged in 
transmitting funds to, from, or on behalf of a party subject 
to a blocking action. If, in the normal course of business, 
the ODFI encounters a transaction initiated by an 
Originator that would violate OFAC-enforced sanctions, 
federal law requires the ODFI to comply with OF AC 
policies. Under U.S. law, the ODFI is responsible for 
freezing or rejecting the proceeds of illicit ACH 
transactions involving interests of blocked parties for 
whom the ODFI holds an account, or on whose behalf the 
ODFI is acting (which could include the Receiver or other 
parties to the transaction). As a depository financial 
institution, the ODFI should have a process in place to 
determine whether any of its account holders is identified 
as a blocked party in a current SDN List (see section on 
"Account Screening" below). 

I. ORIGINATION OF ENTRIES 

With respect to domestic ACH transactions, by addressing 
the issues above, the ODFI may rely on the RDFI for 
compliance with OF AC policies when it is the RDFI that 
holds the account or is otherwise acting on behalf of a 
blocked person. 

With respect to international ACH transactions, the ODFI 
may find it necessary to apply greater scrutiny to 
transaction details, particularly information about the 
Receiver and/or RDFI identified in the transaction. To do 
this, the ODFI may need to process international ACH 
transactions through a separate process that facilitates 
detailed entry scrutiny and minimizes disruption to 
general ACH processing, reconcilement and settlement. 
NACHA recognizes that this means potentially reduced 
efficiency and greater processing costs for international 
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ACH origination since ODFIs would be engaging in 
transaction-level scrutiny rather than account-level 
scrutiny. 

As noted above, the ODFI should address the Originator's 
obligation to comply with U.S. laws in its origination 
agreement. The ODFI should also recognize that when 
unbundling "on us" transactions (i.e., the ODFI is also the 
RDFI for a transaction) from files received for processing 
from an Originator, it will need to review these 
transactions with greater scrutiny since it is servicing both 
the sending and receiving sides. 

2. ENTRIES VIOLATING OFAC SANCTIONS 

Each ODFI should be aware that if it inadvertently 
transmits an unlawful ACH credit entry to a Receiver that 
is subject to OFAC sanctions, the RDFI holding the 
blocked party's account is obligated to post the credit 
entry to the Receiver's account, freeze the proceeds, and 
report the transaction to OFAC. In the event that the 
ODFI inadvertently processes an unlawful ACH debit 
entry to a blocked account, the RDFI holding the blocked 
account (or an intermediary receiving point such as a 
correspondent or Third-Party Service Provider able to 
identify the transaction) , in compliance with OFAC 
policies, should return the entry in accordance with the 
NA CHA Operating Rules using Return Reason Code R 1 6 
(Account Frozen), so that proceeds do not leave the 
blocked account and the ODFI is informed of the reason. 

If the ODFI is instructed to originate an ACH debit entry 
that it has reason to believe would be in violation of 
OFAC sanctions, NACHA has been advised that OFAC 
would prefer that the transaction be transmitted so that, if 
not returned or rejected by the RDFI, the proceeds from 
the transaction can be captured by the ODFI, frozen and 
reported to OFAC. The ODFI should also endeavor to 
notify the RDFI that the transaction sent will be blocked 
by the ODFI and reported to OFAC upon settlement This 
process recognizes that the Receiver may not be on the 
SDN List (or have its account already blocked by the 
RDFI), but OFAC wants the funds blocked if any other 
party to the transaction is on the SDN List when this is 
known to the ODFI. 

In the event the Receiver claims the debit transaction to be 
"unauthorized" under the NACHA Operating Rules, the 
operation of U.S. law in this case means that the RDFI 
(with knowledge of the blocking action by the ODFI) is 
under no obligation to re-credit the Receiver and cannot 
expect a return of the debit from the ODFI. The RDFI 
may, however, require information about the transaction 
for its own research and to share appropriate information 
about the transaction with its Receiver customer who 
might want to file with OFAC for a license to release the 
funds. 

Refer to the section on "Blocking & Reporting" below for 
more detail on the process required to block proceeds of 



a transaction violating OFAC sanctions and report to 
OFAC. 

3. IDENTIFICATION OF BLOCKED PARTIES 

As blocked parties and related transactions may be 
difficult to identify in the normal course of business, 
ODFIs may wish to become familiar with how to locate 
and interpret lists of specially-designated nationals and 
blocked persons subject to U.S. sanctions to facilitate 
OFAC compliance and avoid liability for monetary 
penalties. Consultation with counsel, audit/compliance 
staff, and/or wire transfer operations personnel - in 
addition to visiting and becoming familiar with the OFAC 
website at http://www.treas.gov/offices/eotffc/ofac/ - is 
recommended. There are also several vendors of online or 
database SDN identification services that can assist 
financial institution reviews at the account level, including 
the new account set-up phase or reviewing existing 
accounts when new blocked parties are added to the SDN 
List. : ;■■.■.;'■■;■;: 

G. OBLIGATIONS OF RDFIs 

RDFIs should be aware that they are subject to the 
requirements of the NA CHA Operating Rules and 
applicable U.S. law when processing ACH entries. This 
includes the need to comply with OFAC enforcement 
policies in the event that the RDFI receives an ACH 
transaction being made to, from, or on behalf of any party 
subject to OFAC sanctions. As a depository financial 
institution, the RDFI should have a process in place to 
determine whether any of their account holders is 
identified as a blocked party in a current SDN List (see 
section on "Account Screening" below). 



1. RECEIPT OF ENTRIES 

With respect to domestic ACH transactions, the RDFI is 
responsible for rejecting or freezing the proceeds of a 
transaction involving interests of a blocked party for 
whom the RDFI holds an account or on whose behalf the 
RDFI is acting. If the RDFI is receiving CBR/PBR 
entries, or international ACH transactions through a 
correspondent bank, (see " Third Parties " below), then it 
may find it necessary to review information about the 
Originator/ODFI available in the transaction before 
posting or making funds available to the Receiver 
(recognizing that information identifying the Originator 
by name for purposes of verifying against the SDN list 
may not be present). 

2. ENTRIES VIOLATING OFAC SANCTIONS 

In the event that an ODFI (or Receiving Gateway 
Operator- "RGO" -- with respect to a CBR/PBR entry, or 
a correspondent bank with respect to a foreign-initiated 
ACH transaction) inadvertently transmits an unlawful 
ACH credit entry to a Receiver that is subject to OFAC 
sanctions, the RDFI holding the blocked party's account 
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should post the credit entry to the account, ensure the 
account is frozen, and report the transaction to OFAC. In 
the event that an ODFI (or RGO/correspondent with 
respect to an international ACH entry) inadvertently 
transmits an unlawful ACH debit entry, the RDFI holding 
the account, should return the entry in accordance with the 
NACHA Operating Rules using Return Reason Code Rl 6 
(Account Frozen), with advice that the entry was destined 
to a blocked account and will be reported to OFAC. See 
the section on "Blocking & Reporting" below for more 
detail on the process required to block proceeds of a 
transaction violating OFAC sanctions and report to 

ofac. ■'■.'::■';'■■'■:■':■:■';■ 

3. identification of blocked parties 

As blocked parties and related transactions may be 
difficult to identify in the normal course of business, 
RDFIs may wish to become familiar with how to locate 
and interpret lists of specially-designated nationals and 
blocked persons subj ect to U.S . sanctions to ensure 
compliance and avoid liability for sizeable monetary 
penalties. Consultation with counsel, audit/compliance 
staff, and/or wire transfer operations personnel is 
recommended. 

EL IMPACT TO RECEIVERS 

Domestic Receivers (and those otherwise under U.S. 
jurisdiction) are subject to U.S. law, including OFAC 
sanctions, and should be aware that their financial 
institutions are subject to both U.S. law and the NACHA 
Operating Rules when handling ACH transactions on their 
behalf. This may involve delays in posting, settlement 
and the availability of proceeds -- particularly for ACH 
transactions initiated by parties outside U.S. jurisdiction - 
if an RDFI finds it necessary to scrutinize a transaction in 
more detail. In rare cases where there appears to be a 
violation of U.S. sanctions policies, proceeds from an 
ACH credit may be frozen and therefore unavailable to 
the Receiver pursuant to a blocking action. For ACH 
debits violating OFAC sanctions, Receivers may have the 
proceeds debited from their account and frozen by either 
the RDFI or the ODFI pursuant to a blocking action. 

Receivers wishing to dispute funds frozen in a blocking 
action should review the section on "Blocking & 
Reporting" and/or the OFAC website for the procedures 
and form required to seek a release of funds [Form TD-F 
90-22. .54; Application for 'the 'Release of Blocked Funds]. 

I. THIRD-PARTY SERVICE PROVIDERS 

Third-Party Service Providers (including processors and 
correspondent/respondent banks) should recognize that 
OFAC sanctions enforcement applies to their role as it 
would to the party on whose behalf they are acting. For 
example, a Third-Party Service Provider acting on behalf 
of a number of downstream corporate Originators should 
recognize that its ODFI will hold it accountable for 



ensuring that ACH transactions it introduces into the 
domestic ACH Network comply with U.S. law. This 
means that the ODFI has to rely on the Third-Party 
Service Provider to police downstream parties for which 
it is acting. 

Similarly, a domestic respondent bank/RDFI receiving 
ACH transactions through a correspondent bank should 
not automatically assume that its correspondent will have 
intercepted and frozen any transactions violating OFAC 
sanctions that it has processed on the respondent ' s behalf. 
While there may be some attention focused on the 
correspondent in the event of a transaction violating 
OFAC sanctions being passed through, the correspondent 
serving the RDFI is not in much of a position to verify the 
identity of the RDFFs account holder (or the ODFI's 
Originator) on a particular ACH transaction. 

J. ACCOUNT SCREENING 

While for the most part outside the scope of this guidance, 
which deals specifically with the ACH Network, the issue 
of screening accounts for the purpose of identifying any 
account holding parties subject to a blocking action is 
nonetheless a critical one. Depository financial 
institutions and other enterprises with customers that make 
or receive financial or other trade transactions are 
accountable if their customers are blocked parties on the 
SDN List. OFAC makes the current SDN List available 
to the public through several accessible forms and 
channels (See "For More Information" below). 

Some financial institutions have the capability to 
download this list directly into their account systems as 
changes are made to the list and/or on aperiodic basis to 
ensure that the current version is being applied to review 
their account base and to verify new customers. While it 
is not NACHA's policy to identify specific examples of 
such providers or services, any party interested in 
reviewing availability is encouraged to browse the 
Internet using the keywords "OFAC" and "Compliance." 
There are also several vendors that have OFAC account- 
level screening solutions from which a wide range of 
services are available. Regardless of whether an internal 
or a third-party option is used, the objectives are the same: 

1. Running existing or new account holder information 
against the SDN List to identify those accounts that 
involve the interests of a blocked party (resulting in 
a"hit"); 

2. Reviewing information about a "hit" to establish 
whether the identification is valid, if necessary 
contacting OFAC for verification (caution: more 
"false" hits than true hits are likely given close 
approximations in the names or aliases of individuals 
or companies on the SDN List with the names of 
legitimate individuals or companies); and, 




OGII5 



SECTION IV - SPECIAL TOPICS 
CHAPTER III- OF AC COMPLIANCE 



2005 OPERATING GUIDELINES 




3. Freezing and reporting to OF AC those accounts that 
are true hits. 

K. BLOCKING AND REPORTING 

Blocked accounts and proceeds associated with 
transactions violating OF AC sanctions should be held by 
the financial institution in an interest-bearing status. 
Transactions involving blocked parties should be reported 
via fax within ten days to OFAC's Compliance Programs 
Division. The blocking report should include the name 
and telephone number of a contact at the reporting 
financial institution and, in the case of a frozen ACH 
credit, a copy of the payment instruction (e.g., the 
Company/Batch Header Record and Entry Detail Record). 

Official OF AC reporting, record keeping, and licensing 
procedures . 

Section VII of "Foreign Assets Control Regulations for 
the Financial Community" ( U.S. Department of the 
Treasury, Office of Foreign Assets Control, "Foreign 
Assets Control Regulations for the Financial Community," 
July 3, 2002, pp. 29-30.) states: 

VII. Reporting and Procedures 

Reporting and Procedures Regulations (31 C.F.R. 
Part 501) OF AC now has a uniform requirement 
across all of its sanctions programs that records be 
maintained for five years. 

Reports have also been standardized: 



Reports on Blockings and Reject Items -Blocking 

reports must be filed within 10 days of blocking. 
They preferably should be tele-transmitted to 
OFAC's Compliance Programs Division at 202/622- 
2426 and must identify: the owner or account party, 
the property, the property's location, any existing or 
new account number or similar reference necessary to 
identify the property, actual or estimated value, the 
date it was blocked, a photocopy of the payment or 
transfer instructions (if blocking involves a payment 
or transfer of funds), a confirmation that the payment 
has been deposited into a new or existing blocked 
account which is clearly identifying the interest of, 
the individual or entity subject to blocking, the name 
and address of the holder, and the name and 
telephone number of a contact person from whom 
compliance information can be obtained. Reports on 
reject items must be filed within 10 days and include: 
the name and address of the transferee financial 
institution, the date and amount of transfer, a 
photocopy of the payment or transfer instructions 
received, the basis for rejection, and the name and 
telephone number of a contact person at the 
transferee financial institution from whom 
compliance information can be obtained. 



Annual reports on Blocked Property - OF AC 

requires the filing of a comprehensive annual report 
on blocked property held as of June 30 by September 
30 each year. The report is being filed using Form 
TDF 90-22.50 which is available from OFAC's fax- 
on-demand service or electronically by clicking on 
the GPO ACCESS button on OFAC's Home page or 
going directly to The Federal Bulleting Board and 
accessing OFAC ' s extended electronic information 
reading room, the FACJvIISC file library. Requests 
to submit the information in an alternative format or 
for an extension of the reporting deadline are invited 
and will be considered on a case-by-case basis by 
OFAC. 

Reports on litigation, arbitration and dispute 
resolution proceedings - U.S. persons involved in 
litigation, arbitration, or other binding alternative 
dispute resolution proceedings regarding blocked 
property must: provide notice of such proceedings to 
OFAC Chief Counsel, submit copies of all documents 
associated with such proceedings within 10 days of 
their filing to OFAC Chief Counsel at U.S. Treasury 
Department, 1500 Pennsylvania Ave., NW - 3123 
Annex, Washington, DC 20220, and fax information 
about the scheduling of any hearing or status 
conference to OFAC Chief Counsel at 202/622-1 9 1 1 . 

Licensing requests - License applications are not 
accepted by fax or electronically, unless specifically 
authorized. Most applications may be submitted in 
letter format, with the exception of license 
applications for the unblocking of fund transfers. 
Applications for the unblocking of fund transfers 
must be submitted using TD-F 90-22.54, 
"Application for the Release of Blocked Funds," 
accompanied by two complete copies of the entire 
submission. The form, which requires information 
regarding the date of the blocking, the financial 
institutions involved in the transfer, and the 
beneficiary and the amount of the transfer, may be 
obtained from the OFAC Internet Home Page: 
http://www.treas.gov/offices/eotffc/ofac/ and the 
OFAC fax-on-demand service: 202/622-0077. Any 
person having an interest in a transaction or proposed 
transaction may file an application for a license 
authorizing the transaction. For individuals, if U.S., 
inclusion of a social security number is recommended 
but not required. For corporations or other entities, 
the application should include a principal place of 
business, the state of incorporation or organization, 
and, if U.S., a taxpayer identification number. 
Applications should be sent to the Licensing 
Division, Office of Foreign Assets Control, 1500 
Pennsylvania Avenue, N.W., Annex 2, Washington, 
D.C.20220. 
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L. ADDITIONAL INFORMATION 

The OF AG compliance manual specific to the financial 
community is available on the OF AG website at: 
http://www.1ieas.gov/offices/eotffc/ofac/regulations/tl If 
acbk.pdf. 

OF AC reporting forms .'». including the appropriate forms 
for reporting blocked or rejected transactions, annual 
report of blocked property, and a request for release of 
blocked funds — are available online at: 
http://www.treas.gov/ofFices/eotffc/ofac/foirns^^ 

ACH Network participants are encouraged to check with 
OF AG regularly to determine whether blocked parties 
have been added to the SDN List, or whether other 
modifications to the sanctions programs have taken place. 
OF AG's Compliance Hotline may be reached at (800) 
540-OFAC OF AC also maintains a comprehensive 
website of compliance information, a current SDN List, 
and links to other information referenced above on its 
homepage at: http://www.treas.gov/offices/eotffc/ofac/. 

Finally, OF AC now has an e-mail alert service advising 
recipients of changes as they are approved. To subscribe 
(no charge), go to: http://www.treas.gov/offices/eotffc/ 
ofac/subscribe.html and enter your e-mail address to be 
added to the "OF AC Financial Operations Bulletin E-mail 
List." 



SECTION IV 
SPECIAL TOPICS 

CHAPTER IV 
AUDIT CONTROLS 
AND COMPLIANCE 

A. INTRODUCTION 

The ODFI is responsible for depositing entries into the 
ACH system in a timely manner, according to established 
rules and guidelines. The RDFI is responsible for the 
ultimate disposition of the transactions. Entries must be 
posted and funds made available in an accurate and timely 
manner; exception transactions should be given the same 
handling priority as any other critical financial 
application. Contingency plans should be instituted to 
minimize the adverse impact of exception conditions. In 
order to '.fulfill these responsibilities, the ODFI and the 
RDFI should have audit controls to keep them in 
compliance with NACHA Operating Rules. 

The NACHA Operating Rules require both Participating 
DFIs and any Third-Party Service Providers that perform 



any function of ACH processing on behalf of those 
Participating DFIs to conduct annual audits of rules 
compliance. For information on the specific requirements 
of the audit rule for ODFIs and RDFIs, refer to the 
chapters on ODFIs and RDFIs, respectively, within 
Section II of these Guidelines. Financial institutions 
should note that the audit need only be conducted within 
the four walls of each respective institution. 

This chapter provides information in addition to the actual 
rule and may serve as an outline for design of controls and 
as a guide for participants to use in an audit of their 
controls. An audit may be conducted by the management 
of the appropriate departments or by an internal auditor. 

B. AUDIT CONTROLS 

In the ACH environment, audit controls include both 
administrative and internal accounting controls. 
Administrative controls establish parameters for 
authorization of transactions. Specific administrative 
controls include: 

Organization Controls - organization of the department, 
staffing requirements, and placement of the ACH 
department within the company's organizational structure. 

Training Program - a formal training program designed 
for all levels of personnel to be trained. 

Operating Procedures - formal, detailed, documented 
procedures that regulate schedules and work flow. 

Analysis of Transaction Errors - maintenance of a record 
of errors, with notes on their nature and frequency, to 
indicate basic deficiencies in the total system. 

Risk Controls - control over ACH processing risk to 
determine the overall exposure to the institution, including 
all operating, credit, systems, and processing areas. 

Internal accounting controls increase the reliability of 
financial records. Specific internal accounting controls 
include: 

Segregation of Duties - duties assigned to prevent an 
individual from both initiating and concealing errors, 
either intentionally or accidentally. 




Reconcilement of Input to Output 
balancing batch totals and run totals. 



reconciling and 



Physical Security - control over the physical movement of 
logs, transmission registers, etc., whether received from 
other institutions or transferred internally. 

Management Review - formal review that enables 
management to determine whether operating and 
accounting procedures are being followed. 
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These controls are by no means all-inclusive. Each 
institution must evaluate its own environment and tailor its 
controls accordingly to derive the greatest benefit. 

C. INTERNAL OPERATING CONTROL POINTS 

Because the credibility of the ACH Network depends on 
the efficiency of automated systems and the operating 
procedures developed to support them, human errors must 
be minimized. Even in a sophisticated computerized 
environment, it is important for financial industry 
participants to establish effective controls and procedures 
so they can gain the full benefits and efficiencies of the 
system. 

This section addresses some of the basic internal controls 
and procedures needed to ensure that ACH entries are 
handled efficiently. Although the level of operational 
sophistication will vary, these basic controls and 
procedures apply to all depository participants. 

1. ORIGINATING DEPOSITORY FINANCIAL 
INSTITUTION 

The ODFI is responsible for depositing items into the 
ACH system in a timely manner and in accordance with 
national and local rules. Sound internal controls and 
procedures will help ensure that this responsibility is 
fulfilled. It is important to identify who is responsible for 
ACH functions, including those outside the operations 
department. 

Who is responsible for developing and marketing ACH 
applications? 

Who is responsible for customer contact at the corporate 
and consumer levels? 

Who is the data processing contact? 

Who is the ACH contact? 

Who is responsible for assigning credit limits to the 
customer? 

Who is responsible for monitoring and tracking exposure 
limits? 

Who will determine how a customer file will be handled 
if exposure limits are exceeded? 

The various responsibilities for ACH services may be 
vested in a single individual or within several functional 
groups. In either case, a clear definition of 
responsibilities and effective communication among all 
parties is essential to the success of any ACH program. 



Establishing Exposure Limits 

In an effort to reduce its exposure to risk associated with 
originating ACH credit and debit entries on behalf of its 
customers, ODFIs are required to (1) establish exposure 
limits for each of its corporate Originators or Third-Party 
Senders, (2) implement procedures to review those 
exposure limits periodically, (3) implement procedures to 
monitor entries initiated by each Originator or Third-Party 
Sender relative to its exposure limit across multiple 
settlement dates, and (4) implement procedures to monitor 
payment system risk associated with CBR and PBR 
entries initiated by that Originator or Third-Party Sender. 

ODFIs are also required to establish specific exposure 
limits for Internet-Initiated Entries. Specifically, for each 
WEB entry initiated by an Originator that is not a natural 
person or by a Third-Party Sender, ODFIs are required to 
( 1 ) establish procedures to monitor the credit- worthiness 
of that Originator or Third-Party Sender on an on-going 
basis, (2) establish an exposure limit for that Originator or 
Third-Party Sender, (3) implement procedures to review 
that exposure limit periodically, and (5) implement 
procedures to monitor entries initiated by that Originator 
or Third-Party Sender relative to its exposure limit across 
multiple settlement dates. 

The following recommendations will assist ODFIs in 
assigning exposure limits to each customer file: 

• develop a process to monitor and track exposure limits 
for all corporate clients; 

• provide flexibility and establish contingency plans to 
accommodate the handling of exception situations; 

• coordinate efforts between the operations and banking 
departments to manage this process; and 

• establish and document processing procedures and 
responsibilities for monitoring exposure limits. 

Establishing Priority Schedules 

The consequences of failing to comply with ACH 
procedures are no less severe than for paper transactions. 
For example, if a payroll credit does not reach the 
employee's account in time for payday, customer 
relationships on both the originating and receiving side of 
the transaction could be affected. 

To provide efficient service, daily processing schedules 
should be established for deposits of local ACH entries, 
remakes, and interregional entries. The following 
procedures for originating ACH files are recommended: 

a. Schedule the receipt of files from each company: 

•■ develop a calendar indicating applicable 
processing dates, times, etc.; 
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provide adequate flexibility so that file 
remakes/reversals can be accommodated if 
necessary; and 

•establish contingency procedures to 
accommodate late file deliveries. 

b. Establish and document scheduled processing times 
in the computer operations department, and make 
timely processing a high priority in employee 
evaluations. 

c. Establish and document a schedule for the prompt 
handling of exception conditions using the following 
checklist of items: / 

v out-of-balance file; 

• ■ ■ non-receipt of a file; 

.'•'■' lost file; 

• inoperative computer or data transmission 
system; 

.•'. unreadable file; 

• rejection of a file by the ACH Operator; and 

;•: rejected batches and unroutable entries. 

In addition, a schedule should be established for editing 
all originating ACH files. As a precaution against loss or 
damage, the files must be copied. This procedure also 
ensures that the file can be read and processed. 

Establishing an ACH Operational Control Group 

It is essential that an individual or group be assigned 
responsibility for monitoring and controlling ACH 
operations and related maintenance tasks. The ACH 
control group should be responsible for : 

• accepting company files, completing customer 
information sheets, and maintaining a "due-in" schedule 
or processing calendar; 

.'.• balancing and controlling all input and distributing 
output from ACH files; 

• verifying ACH billing and generating statistics; 

'• controlling and processing return entries (including 
returned prenotification and notification of change 
entries); 

• responding to customer inquiries ; 

/• balancing and controlling settlement entries; 



.• ensuring that settlement advices are received from the 
ACH Operator in a timely manner; 

• notifying RDFIs, originating companies, ODFI data 
processor, and the ACH Operator when deliveries are 
late, schedules are missed, or there are other processing 
problems; 

• processing dishonored and contested dishonored return 
items; and 

■• ensuring the Central Information File (CIF) at the ACH 
Operator reflects accurate data for the financial 
institution. 

The ACH control group should also maintain an ACH log 
with: 

•'.■ Receipt of file and control documents from originating 
companies noting: 

name of person who called. 

- reference number of file. 

■ - . ■ date and time the file was received. 

magnetic tape reel number, diskette or file 
number. 

■ - dollar value of the file. 

- company name. 

- number of entries. 

- effective entry date. 

•Total debits and credits representing on-us entries 
noting: 

.-'.■■ balance of ACH warehouse entries, by release 
date. 

time each file is submitted to or received from 
the computer center. 

- reason for and disposition of all exception 
entries. 

Contingency Planning 

Contingency plans should be developed and documented 
to handle exception conditions in a timely, accurate, and 
efficient manner. From the ODFI's perspective, a number 
of factors must be considered in executing contingency 
plans: 

a. Exception Conditions: 

• duplicate file(s); 

late delivery from the originating company; 

.'•■ lost files; 

■ files that cannot be processed or read; 

« files not received; and 
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files, batches, or entries that were rejected by the 
ACHOperator. 

b. Operational Considerations: 

company remake capabilities: 

■■■.-' is there adequate time to resubmit and still 
make deadlines? 
- should schedules provide for 
remakes/reversals and resubmission? 




ODFI remake capabilities: 

- is there adequate time to remake/reverse and 
still meet deadlines? 

- can remakes/reversals be handled at the 
batch/entry level? 

■■/■':-: is computer resource allocation available for 
reprocessing? 

- have back-up computer resources been 
identified in the event of a major systems 
failure? 



c. Missed Deadlines: 



Do settlement totals need to be adjusted? 

Should funds be wired to customers if there are 
large dollar credits? 

Who needs to be notified if a processing 
deadline is missed? 



(when 



- the originating company? 

- the ACHOperator? 

- receiving financial institutions 
possible)? 

.-.' internal tellers and customer service staff 
(for on-us entries)? 

RECEIVING DEPOSITORY FINANCIAL 
INSTITUTION 



Controls and procedures similar to those of the ODFI 
apply also to the RDFI, which has the additional 
responsibility of posting the ACH transaction to the 
customer's account. 

Establishing Priority Schedules 

Daily processing schedules should be established to 
ensure that transactions are posted to the customer's 
account within the prescribed time frames. The following 
procedures are recommended: 

• Maintain a schedule of files due daily from the ACH 
Operator. Update this schedule regularly. 



1 Pick up files in the afternoon to ensure opening of 
business availability for PPD credits. 

1 Establish scheduled processing times in computer 
operations. Files should be processed during the same 
processing cycle in which they were received from the 
ACH Operator. Consider priority scheduling if the 
ACH Operator is required to resubmit a file, e.g., a file 
is lost, cannot be processed, or contains errors. 

Establish a schedule for prompt handling of exception 
transactions: 

■■;■■- prenotifications. 

notifications of change. 
- return items. 

.- ■ ■ dishonored and contested dishonored return 
claims. 

Assign responsibility and accountability for the various 
functions in ACH transaction processing. 

Establish time frames for handling transactions on a 
dailybasis. 

Provide for memo crediting to ensure that funds are 
available on the Settlement Date. If memo posting is 
not possible, communicate the information to tellers and 
customer service staff. 



Establishing an ACH Operational Control Group 



In most cases, the ACH control group established to 
monitor and control receiving entries will have the same 
responsibilities as the originating functions. In addition, 
there may be other responsibilities such as notifying 
appropriate parties when deadlines are missed or when 
entries cannot be posted on the Settlement Date . 

If posting deadlines are missed for credit transactions, 
notify tellers, the local ACH Operator, the ODFI, and 
other internal departments as dictated by individual 
organizational structure. Procedures should be in place 
for making funds available to customers for cash 
withdrawal on Settlement Date regardless of late posting. 

Contingency Planning 

For the RDFI, certain factors must be considered when 
developing contingency plans. 

a. Exception conditions: 

late receipt of files from the ACH Operator or 
Receiving Point; 

lost files; 

•. files that cannot be processed; 
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erroneous data on the files; 

• duplicate files; and 

files received in error (intended for another 
RDFI). 

b. Operational considerations: 

'■/'•■;'■ Is the AGH processing schedule sufficiently 
flexible to handle late delivery? 

• Is there an alternative delivery location in case 
there is a late delivery? 

V What are the processing options in case there are 
some erroneous transactions on the file? Can a 
batch be processed alone? 

> What memo posting capabilities are available? 

c. Contingency Management: 

When contingency plans go into effect, who needs to 
be notified? 

• tellers, customer service personnel 

■■-■' '- ;odfi';.' ; ^ 

• ACH Operator 

• local ACH Association 

D. COMPLIANCE CHECK LIST 

The following check list is intended to help each 
institution comply with NACH A Operating Rules. 

1. Obtain all available resources, such as rules, 
regulations, guidelines, etc. Keep them up to date. 

2. Develop a list of contacts to use as needed. Make 
their addresses and telephone numbers available to 
those that need them. 

3 . Maintain current ACH software. 

4. Periodically review current callback and 
authentication techniques to ensure that your security 
measures are adequate. 

5. Establish proper control procedures and use them. 

6. Consult the appropriate auditor/independent 
accountant in establishing proper security and control 
procedures. 



7. Respond to all Reports of Possible ACH Rules 
Violation received by correcting or refuting the 
alleged rules violation. 

Questions for the ODFI: 

• Do you have each company execute an originating 
company agreement that, at a minimum, binds that 
company to the NACH A Operating Rules? 

•'■ Do you have an agreement with each Sending Point 
used? 

• Have you established procedures for evaluating credit 
risk for each of your originating companies? 

• Have you reviewed internal procedures to determine 
that exposure limits are established for each corporate 
Originator or Third-Party Sender, that these procedures 
provide for the exposure limits to be reviewed 
periodically, and for entries initiated by these 
Originators or Third-Party Senders to be monitored 
relative to the exposure limits across multiple 
settlement dates? Do such procedures ensure that the 
ODFI monitors payment system risk associated with 
CBR and PBR entries initiated by that Originator or 
Third-Party Sender? With respect to WEB entries, do 
such procedures ensure that the ODFI has established 
procedures to monitor me credit worthiness of each 
Originator or Third-Party Sender on an on-going basis? 

• Have you established priorities and processing 
schedules for each company? 

• Do you have a complete service specification sheet for 
each company? A company agreement letter? Other 
documentation? 

• Are corporate customers aware of return deadlines and 
rules regarding reinitiation of entries? 

• Has an ACH operational control group been 
established? 

• Have you assigned responsibility and accountability for: 

- verifying authenticity of files? 

- reviewing controls and checks? 
balancing controls? 

- ensuring prompt, accurate processing? 

- researching inquiries, errors? 

• Have you developed backup/contingency plans? 



Have you verified that the formats and structure of the 
ACH files you process meet all criteria and edits? 

Do you check holiday schedules? Do your companies 
check these schedules? 
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9 Is the required information from Notifications of 
Change forwarded to the Originator within therequired 
timeframe? Does the Originator make the appropriate 
changes within the prescribed time frames? 

• When your Originators choose to utilize the 
prenotification process, do they comply with all 
requirements governing these entries? 

• Do your Originators review returns relating to 
prenotifications? Do they ensure that live entries are 
not originated when a prenotification is returned? 

• Do you accept permissible return entries when you have 
agreed to do so? 

• . Do you transmit reversing entries and reversing files to 
the Receiving ACH Operator so that they are made 
available to the RDFI within five banking days 
following the settlement date of the erroneous entry or 
file? 

• For WEB entries, have your Originators employed 
commercially reasonable methods of authentication to 
verify the identity of the Receiver? Have your 
Originators employed commercially reasonable 
fraudulent transaction detection systems to screen such 
entries? Have your Originators used commercially 
reasonable procedures to verify the validity of routing 
numbers? Have your Originators conducted annual 
audits to ensure that financial information obtained 
from Receivers is protected by adequate security 
practices and procedures? 

• For TEL entries, have your Originators employed 
commercially reasonable procedures to verify the 
Receiver's identity and to verify that routing numbers 
are valid? 

Questions far the RDFI: 

•. Have you established priorities/schedules? 

• Have you established an ACH operational control 
group? 

• Do you accept all types of ACH entries as required by 
the NACHA Operating Rules? 

• Do you post entries on a timely basis? 



Do you review prenotifications and initiate the 
appropriate entry (return or notification of change) as 
required by NACHA Operating Rules? 

Do you make funds available to customers on 
settlement date? 

Do you make funds available for PPD credits at 
opening of business on settlement date? 



• Do you require a Receiver to sign a written statement 
under penalty of perjury before returning an entry for 
R05 (effective March 18, 2005), R07, RIO, R37, R51, 
or R53? Are adjustment entries initiated within the 
appropriate time frame? (Note: For additional 
information on written statements under penalty of 
perjury, refer to the chapter on RDFIs in Section II of 
these Guidelines.) 

: Do you provide the appropriate information to your 
customers on their statements? 

Are returns initiated in a timely manner? Are contested 
dishonored returns and corrected returns initiated in a 
timely manner? 

Do you handle addenda records appropriately? 

• Do you transmit Notifications of Change and Corrected 
Notifications of Change within the time frames required 
by the NACHA Operating Rules? 

• When requested to do so by the Receiver, do you 
provide all payment-related information transmitted 
withCCD, CIE, and CTX entries to the Receiver within 
the appropriate time frame? 

• With regard to RCK entries, do you transmit returns of 
these entries within the time frames required by the 
NACHA Operating Rules? 

E. ACH RULES ENFORCEMENT 

The objective of the rules enforcement process contained 
within the NACHA Operating Rules is to maintain the 
quality of ACH services and the satisfaction of 
Participating DFIs and their customers by ensuring 
compliance by Participating DFIs with the NACHA 
Operating Rules through the National System of Fines. 
This rules enforcement process provides a mechanism for 
formal documentation by a party to an ACH transaction of 
an alleged rules violation, outlining specific requirements 
for the reporting and investigation of possible ACH rules 
violations/Assistance with compliance issues and quality 
concerns is also available through many regional ACH 
associations, which have established their own 
mechanisms for reporting incidents of possible ACH rules 
violations. For detailed information on reporting an 
incident of non-compliance with the requirements of the 
NACHA Operating Rules, please contact your regional 
ACH association or refer to the chapter on the National 
System of Fines within these Guidelines. 
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SECTION IV 
SPECIAL TOPICS 

CHAPTER V 

NATIONAL SYSTEM OF FINES 

A. INTRODUCTION 

This chapter is designed to provide ACH participants with 
an understanding of the formal process, known as the 
National System of Fines, for the documentation and 
investigation of alleged violations of the NACHA 
Operating Rules. The objective of this National System 
of Fines, which is defined by the NACHA Operating 
Rules, is to maintain the continued quality of ACH 
services and the satisfaction of Participating DFIs and 
their customers by ensuring compliance by Participating 
DFIs with the provisions of the NACHA Operating Rules . 

B. REPORTING OF POSSIBLE RULES 
EOLATIONS 

The National System of Fines may be utilized for any 
alleged violation of the provisions of the NACHA 
Operating Rules. To file a complaint under the National 
System of Fines, the complainant (a Participating DFI or 
other ACH participant) must be a party to the transaction. 
It must be clearly noted that the National Association does 
not, based on the receipt of a Report of Possible ACH 
Rules Violation, assume any wrongdoing on the part of 
the Participating DFI against which an allegation is made; 
Rather^ use of the National System of Fines provides an 
opportunity for a formal review and evaluation of the 
circumstances surrounding any possible rules violation 
associated with the handling of an ACH transaction. Any 
Participating DFI against which a Report of Possible ACH 
Rules Violation is submitted will be provided with the 
opportunity to investigate and respond to the claim of an 
alleged rules violation. 



i; REQUIRED FORMS AND DOCUMENTATION 

A claim of a rules violation under the National System of 
Fines may be initiated by a party to an ACH transaction 
through the completion and submission of the Report of 
Possible ACH Rules Violation provided within this 
chapter. 

Identification of Parties 

The Report of Possible ACH Rules Violation must 
include complete information to identify both the 
complainant and the party against which the Report is 
being filed (the respondent). Required data includes the 
names, addresses, and telephone numbers of both parties, 



along with the routing number of the party against which 
the Report is being filed. If either the complainant or the 
respondent is not a Participating DFI (i.e., is not the ODFI 
or the RDFI), information must also be provided to enable 
the National Association to identify the ODFI and the 
RDFI. 

Summary of Facts Surrounding Alleged Rules Violation 

The Report of Possible ACH Rules Violation must 
contain a description of the precise nature of the alleged 
rules violation^ the sequence of events involved, and a 
description of the consequences resulting from the alleged 
violation. The Report must specify the provision of the 
NACHA Operating Rules that is believed to have been 
violated, along with information that permits the 
identification of the particular transaction (i.e., Standard 
Entry Class Code, Transaction Code, Effective Entry 
Date, Dollar Amount, Trace Number, Date of Alleged 
Rules Violation, and Account Number). 




Supporting Documentation 

The Report of Possible ACH Rules Violation should be 
accompanied by copies of all documents necessary to 
support the claim that a provision of the NACHA 
Operating Rules has been violated, including copies of 
any written communications between the complainant and 
the party against which the Report is being filed. 

Authorization for Submitting a Report of Possible ACH 
Rules Violation 

The Report of Possible ACH Rules Violation must be 
signed by an officer of the complainant. 

Restrictions on Filing a Report of Possible ACH Rules 
Violation 

A Report of Possible ACH Rules Violation must be 
submitted to the National Association by the complainant 
within ninety (90) days of the occurrence of the rules 
violation(s) being asserted. Completed forms and 
supporting documentation should be directed to: 

NACHA - Network Services Department 
13665 Dulles Technology Drive, Suite 300 
Herndon,VA 20171 
fax:(703)561-0819 

The Report of Possible ACH Rules Violation may be 
submitted via U.S. mail, fax, or by Internet submission at 
https://www.nacha.org/ACH_Rules/National_System_o 
f_Fines/national_system_of_fmes.htm. 

2. COMPLAINTS INVOLVING MULTIPLE 
PARTICIPATING DFIs 

In the event that the complainant is asserting that a rules 
violation has been committed by more than one 



OG 123 



SECTION IV - SPECIAL TOPICS 

CHAPTER V -NATIONAL SYSTEM OF FINES 



2005 OPERA TING GUIDELINES 



Participating DFI, a separate Report of Possible ACH 
Rules Violation must be filed for each Participating DFI. 

C, INVESTIGATION OF ALLEGED RULES 
VIOLATIONS 




1. RECEIPT OF REPORT OF POSSIBLE RULES 

VIOLATION BY NATIONAL ASSOCIATION 

Once received by the National Association, each Report 
of Possible ACH Rules Violation and the supporting 
documentation are reviewed, and a preliminary evaluation 
of the circumstances surrounding the alleged rules 
violation is made. 

So that regional ACH associations and/or the Federal 
Reserve may provide assistance to their members with 
respect to a Report of Possible ACH Rules Violation^ an 
informational copy of the Report will be forwarded to the 
regional ACH association of both the complainant and the 
Participating DFI against which the Report has been filed. 
If either party is not a member of a regional ACH 
association, an informational copy of this information will 
be forwarded to the local Federal Reserve Bank. 

If, based on the information provided in the Report of 
Possible ACH Rules Violation and supporting 
documentation, it appears that a violation of the NACHA 
Operating Rules may have taken place, a Notice of 
Possible ACH Rules Violation will be sent to the ACH 
Manager at the Participating DFI against which the Report 
was filed. Provided that all information and supporting 
documentation relating to a claim of a rules violation is 
complete, this Notice of Possible ACH Rules Violation 
will be sent by the National Association within five 
banking days from receipt of the Report of Possible ACH 
Rules Violation using a traceable delivery method (i.e., 
certified mail with return receipt requested, etc.). This 
Notice will explain that an infraction of a specific 
section(s)oftheAC4C/£4 Operating Rules appears to have 
occurred and that, unless the violation is corrected or 
refuted, the Participating DFI may be subject to the 
imposition of a fine. 

Violations Causing Significant Harm to DFIs 

Any Report of Possible ACH Rules Violation that is 
received by the National Association alleging a rules 
violation that the National Association believes causes 
significant harm to other financial institutions will result 
in the generation of a Notice of Possible Fine, which will 
be forwarded to both the ACH Manager and the Chief 
Operating Officer of the financial institution. The 
financial institution will be afforded an opportunity to 
investigate the claim of a rules violation and refute the 
claim before any fine is imposed. The financial institution 
must respond to the Notice of Possible Fine within ten 
banking days of receipt of the Notice. 



In any case where the National Association believes the 
violation causes significant harm, the issue will be 
forwarded directly to the ACH Rules Enforcement Panel 
for review. Should the ACH Rules Enforcement Panel 
determine that significant harm has been caused by the 
alleged violation, and, therefore, constitutes willful 
disregard, a fine maybe assessed against the respondent 
financial institution. 

2. PARTICIPATING DFI ACTION ON RECEIPT 
OF NOTICE OF POSSIBLE ACH RULES 

VIOLATION 

A Participating DFI that has received a Notice of Possible 
ACH Rules Violation will be asked to respond to the 
allegation of a rules violation within fifteen banking days 
of receipt of the Notice of Possible ACH Rules Violation. 
This response, utilizing the Notice of Possible ACH Rules 
Violation Response Form and sent via traceable delivery 
method, must contain a statement from the Participating 
DFI either (1) acknowledging that the violation occurred 
and stating an intent to correct the problem causing it, or 
(2) refuting the allegation that it violated the rules. An 
acknowledgment of the rules violation must also contain 
a date by which the Participating DFI will correct the 
violation (the Resolution Date). A statement refuting the 
allegation of a rules violation must contain appropriate 
supporting documentation. 



3. NATIONAL ASSOCIATION ACTION ON 
PARTICIPATING DFI RESPONSE 

If the National Association receives, within fifteen 
banking days of receipt of the Report of Possible ACH 
Rules Violation, a Notice of Possible ACH Rules 
Violation Response Form from the Participating DFI 
against which the Report of Possible ACH Rules 
Violation was filed, indicating that the participant either 
( 1 ) acknowledges that an alleged rules violation occurred 
and will correct the problem causing the rules violation, 
or (2) refutes the allegation of a rules violation with 
appropriate documentation, no additional action will be 
taken by the National Association at that time. However, 
in the event that a Participating DFI (1) acknowledges a 
rules violation but indicates a Resolution Date that seems 
to be excessive, or (2) indicates that it does not intend to 
correct the problem causing the rules violation, the 
National Association will forward the issue to the ACH 
Rules Enforcement Panel for additional review and 
possible imposition of a fine. 



4. NATIONAL ASSOCIATION ACTION ON NON- 
RESPONSE TO NOTICE OF POSSIBLE RULES 
VIOLATION OR RECURRENCE OF RULES 

...VIOLATION. ... : :;.;:. 

The recurrence of a rules violation for which a Notice of 
Possible ACH Rules Violation was previously sent by the 
National Association or the failure of the financial 
institution to respond to a Notice of Possible Rules 
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Violation will result in the generation of a Notice of 
Possible Fine, which will be forwarded to both the ACH 
Manager and the Chief Operating Officer of the financial 
institution. The financial institution will be afforded an 
opportunity to investigate the claim of a rules violation 
and refute the claim before any fine is imposed. The 
financial institution must respond to the Notice of 
Possible Fine within ten banking days of receipt of the 
Notice. 

5. PARTICIPATING DFI ACTION ON NOTICE 
OF POSSIBLE FINE 

A Participating DFI that has received a Notice of Possible 
Fine will be asked to respond to the allegation of a rules 
violation within ten banking days of receipt of the Notice 
of Possible Fine. This response, utilizing a Notice of 
Possible Fine Response Form and sent via traceable 
delivery method, must contain a statement from the 
Participating DFI either (1) acknowledging that the 
violation occurred and stating an intent to correct the 
problem causing it, or (2) refuting the allegation that it 
violated the rules. An acknowledgment of the rules 
violation must also contain a date by which the 
Participating DFI will correct the problem (the Resolution 
Date). A statement refuting the allegation of a rules 
violation should contain appropriate supporting 
documentation. 



Imposition of Fines 

As a Participating DFI subject to the terms of theNACHA 
Operating Rules, the DFI inherently agrees to the payment 
of any fines in accordance with the National System of 
Fines. Any fine imposed upon a Participating DFI will be 
collected by the National Association via the transmission 
of an ACH debit entry to an account of the DFL 

Participating DFIs must be aware that no written 
authorization for this type of debit entry will be obtained 
prior to the initiation of the debit entry to collect the fine; 
however, notice will be provided to the Participating DFI, 
at least seven banking days in advance of the Settlement 
Date of the debit, indicating the date and the amount of 
the debit. 



Determination of Fines 

Any fine(s) levied against a Participating DFI for a 
violation of the NA CHA Operating Rules will be 
determined based on an evaluation by the National 
Association of whether the rules violation is a recurrence 
of a problem previously acknowledged by the 
Participating DFI or whether the rules violation has 
continued to occur due to the willful disregard by the 
Participating DFI of the problem causing the rules 
violation. 




6. NATIONAL ASSOCIATION ACTION ON 
PARTICIPATING DFI RESPONSE 

If a Participating DFI refutes the allegation of a rules 
violation and provides sufficient documentation to support 
the claim, no additional action will be taken by the 
National Association at that time, However, an 
acknowledgment by the respondent financial institution 
that a rules violation has occurred or the failure of the 
financial institution to respond to the Notice of Possible 
Fine will result in the issue being forwarded to the ACH 
Rules Enforcement Panel for evaluation and possible 
imposition of a fine in accordance with the requirements 
of Appendix Eleven of the NACHA Operating Rules. 

7. IMPOSITION OF FINES 

A Participating DFI that (1) fails to correct a problem 
causing a rules violation after receiving a Notice of 
Possible Rules Violation, resulting in a recurrence of the 
violation, (2) fails to respond to a Notice of Possible 
Rules Violation, (3) responds to the Notice of Possible 
Rules Violation that it does not intend to correct the 
problem causing the rules violation, (4) causes significant 
harm to another financial institution, or (5) asserts a 
resolution date that is excessive may be assessed a fine by 
the ACH Rules Enforcement Panel in accordance with the 
requirements of the NA CHA Operating Rules. 



Recurrence 

A rules violation is considered to be a recurrence of a 
previously reported infraction of the NACHA Operating 
Rulesif: 

• the same infraction is committed by the same Originator 
that transmits through the ODFI within the one-year 
period following the Resolution Date of the initial rules 
violation identified in the Notice of Possible ACH 
Rules Violation. 

• the same infraction is committed by the same Third- 
Party Service Provider transmitting through or on 
behalf of an ODFI or receiving on behalf of an RDFI 
within the one-year period following the Resolution 
Date of the initial rules violation identified in the Notice 
of Possible ACH Rules Violation. 

• the same infraction is committed by the same ODFI or 
RDFI within the one-year period following the 
Resolution Date of the initial rules violation identified 
in the Notice of Possible ACH Rules Violation. 

The first recurrence of a rules violation that causes a fine 
to be levied by the National Association will result in an 
assessment of $250 against the Participating DFL The 
second recurrence of a rules violation that causes a fine to 
be levied by the National Association will result in an 
assessment of $750 against the Participating DFI. The 
third recurrence of a rules violation that causes a fine to 
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be levied by the National Association will result in an 
assessment of $1,500 against the Participating DFI. (See 
below for a discussion on fines relating to willful 
disregard.) 

It should be noted that receipt of an initial Report of 
Possible ACH Rules Violation will trigger action and 
investigation on the part of the National Association. Any 
Reports alleging the same violation by the same 
Participating DFI or Originator that are received 
subsequent to the initial Report but prior to the Resolution 
Date provided by the financial institution will not result in 
additional investigative action by the National Association 
at that time. Instead, such Reports will be kept on file and 
the complainants notified that the alleged violation is 
currently being addressed. Any Reports alleging the same 
rules violation by the same Participating DFI, Originator, 
or third party service provider received within one year 
following the Resolution Date of the initial rules violation 
(as indicated by the resolution date contained in the 
Notice of Possible Rules Violation Response Form) will 
be considered to be recurrences of the initial rules 
violation and will result in the generation of a Notice of 
Possible Fine to the participating DFI. 



Willful Disregard 

A rules violation that has occurred due to the willful 
disregard by a Participating DFI is one in which: 

• the Participating DFI has not responded to either the 
Notice of Possible ACH Rules Violation or to the 
Notice of Possible Fine; 

•. the Participating DFI responds to either notice that it 
does not intend to correct the rules violation; 

• the ACH Rules Enforcement Panel believes the time 
frame and Resolution Date asserted by a financial 
institution as necessary to resolve the problem causing 
the rules violation are excessive; 

• the ACH Rules Enforcement Panel believes that the 
violation significantly harms other financial institutions; 

• it is the fourth recurrence of the same rules violation; or 

• the ODFI has failed to provide reporting information 
for unauthorized TEL entries in accordance with the 
requirements of the NACHA Operating Rules. 

The fine levied against a Participating DFI for the willful 
disregard of an ACH rules violation will be in the amount 
of $10,000 per month until the problem is resolved. 

D. RESOLUTION OF COMPLAINT 

The National Association will notify each complainant 
upon the resolution of the investigation of the alleged 
rules violation that either the violation has been resolved, 



or will be resolved within a specified time period, or that 
the ACH participant has responded by refuting the 
allegation that a violation of the NA CHA Operating Rules 
has occurred. 

E. RELEASE OF RETURN DATA BY ACH 
OPERATORS 

ACH Operators provide the National Association with 
statistical data relating to the volume and types of ACH 
return entries received by Participating DFIs on behalf of 
their Originators. This information is used by NACHA to 
help identify areas of potential fraud within the ACH 
Network by identifying ODFIs that receive an unusually 
high volume of certain types of returns on behalf of their 
Originators. Excessive numbers of returns for certain 
types of return reason codes, such as unauthorized or stop 
payment, may indicate the possibility that an Originator 
is engaged in fraudulent or unscrupulous business 
activities. NACHA monitors the return information 
provided by the ACH Operators and alerts an ODFI if it 
believes closer examination of an Originator is necessary. 
ACH participants should note that any information related 
to individual transactions that may be provided to 
NACHA by the ACH Operators is kept confidential and 
is used by NACHA only for risk management purposes. 

F. RULES ENFORCEMENT PANEL 

1. RESPONSIBILITIES OF RULES 
ENFORCEMENT PANEL 

The ACH Rules Enforcement Panel is the final authority 
with respect to the imposition of a fine against a 
Participating DFI for a violation of the NA CHA Operating 
Rules or when the Participating DFI does not respond to 
the Notices in a timely manner. The Panel also has 
decision-making responsibility in circumstances in which 
the National Association staff determines that it is unclear 
whether amies violation has occurred. To conduct Panel 
business, a quorum of the Panel (five of the seven Panel 
members or alternates) must be present. A vote of four or 
more Panel members or alternates is necessary to approve 
a decision of the Panel. 

2. SELECTION OF RULES ENFORCEMENT 

PANEL 

The ACH Rules Enforcement Panel is comprised of 
volunteer members representing the following industry 
participants: 

• the Federal Reserve Bank; 

• a private-sector ACH Operator; 

• a large asset size (greater than $ 1. billion) commercial 
bank or savings institution; 

• a small asset size (less than $ 1 billion) commercial bank 
or savings institution; 

.• a credit union; 

• a regional ACH association; and 
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• a NACHA Affiliate Program member. 

Seven alternates are chosen to provide representation on 
the Panel in circumstances in which a conflict of interest 
exists or when an appointed member is unavailable for a 
meeting. All nominations to the Panel are subject to the 
approval of the NACHA Board of Directors. 
Representatives to the Panel serve a three-year term. 
National Association staff participates on the Panel as a 
facilitator in a non-voting, advisory capacity. 



Each Panel member must have a thorough knowledge and 
understanding of the ACH Network and of the NA CHA 
Operating Rules and NACHA Operating Guidelines, 
Preference for selection to the Panel is given to nominees 
demonstrating one or more of the following criteria: 

• current Accredited ACH Professional (AAP) 
accreditation; 

• a minimum of three years' experience with ACH 
payments; 

•; current or past membership on NACHA's Rules & 
Operations Committee, other NACHA standing 
committee, or a Rules Work Group; 

v a current or past member of NACHA's Board of 
Directors; 

•'. a current or past role as a regional Association 
Executive; or 

• a person serving in an official capacity on behalf of a 
regional ACH association. 

3. CONFIDENTIALITY OF INFORMATION 

ACH Rules Enforcement Panel members are required to 
maintain the confidentiality of all information disclosed 
concerning participants in the enforcement process. ACH 
Rules Enforcement Panel members, as a condition of their 
appointment to the Panel, must sign an agreement with the 
National Association acknowledging that they will not, to 
the extent allowable by law, disclose any information 
relating to the decisions of the Panel or any parties to the 
rules enforcement process. 
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NATIONAL SYSTEM OF FINES 
REPORT OF POSSIBLE ACH RULES VIOLATION 

Completed form and necessary documentation should be returned to: 

Network Services Department 

NACHA, 13665 Dulles Technology Drive, Suite 300, Herndon, VA 20171 

Phone: (703) 561-1100; Fax: (703) 561-0819 

Internet submission: https://www.nacha.org/ACH_Rules/National_System_or Fines/national_system_of Jines.htm 




Receiving Depository Financial Institution 

RDFTName RDFI Routing Number 

RDFI Contact ■' - '' ' ' ' ■ '■" ' : ' : - ' - " "' - " : " Title . 



Street Address ■ ■ ■ " " : ' /; ■'■■■• ■ ; "■• ; ■ " ■ " ' ■ " ■■' City/State/Zip _ 

Telephone ( ) _______________ Fax ( ) _______________ .E-Mail . 

Regional Payments Association Member? O Yes D No If yes, specify association: •■■■■■■■•■ ■ ; ■ ; 
O Submitter of Violation Report 

Originating Depository Financial Institution 



QDFIName ________—_——. ODFI Routing Number 

ODFI Contact Title 



Street Address ___________________________ — City/State/Zip _ 

Telephone ( ) Fax ( ) /■■ E-Mail . 

Regional Payments Association Member? O Yes O No If yes, specify association: ;■-■-■ ■■ ■; ■■■ ;■■■■ 
O Submitter of Violation Report 

Originator 



Originator Name Company ID Number 



Title 



Contact — 

Street Address " ■ ■ ' ' ' ■ ■' " ' ' ■ v ■ ' '- ■■■■■■■• ■" City/State/Zip _ 

Telephone ( ^ Fax ( )___ ________ E-Mail . 

D Submitter of Violation Report 

If Other ACH Participant, Complete This Section 

O ACH Operator O Third-Party Service Provider □ Receiver (Please check appropriate box) 



Company 
Contact 



Title 



Street ah,W ______ City/State/Zip _ 

Telephone! V Fax( ) E-Mail. 

□ Submitter of Violation Report 



Description of Rules Violation 

Standard Entry Class Code for Entry Transaction Code . 

Settlement Date ______________________ '. Dollar Amount __ 

Trace Number " ■ ■ ' ■ ' ' " ■ : ' ; ' ' " .■' , ; '- ; '. ■ Account Number - 

Date of Alleged Rules Violation (if different from Settlement Date above) __ __ 

Article and Section of NACHA Operating Rules alleged to have been violated (required) _____ 



Describe the precise nature of the alleged ACH rules violation. Appropriate documentation of the alleged rules violation must be provided. 



Signature of Officer of Complainant . 



Title: _________„_ Date - 
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HOW TO COMPLETE THE FORM 



To report an alleged violation of the NA CHA Operating Rules, the complainant must submit a completed and signed 
Report of Possible ACH Rules Violation form, along with documentation necessary to support the claim of a violation, 
to: Network Services Department, NACHA, 13665 Dulles Technology Drive, Suite 300, Herndon, VA 20171; phone: 
(703) 561-1 100; fax: (703) 561-0819. The form may also be submitted over the Internet by accessing NACHA' s website 
at https://www.nacha.org/AGH_Rules/National__ System__of_Fines/national_system_of_fines. 
htm. 

Identification of Parties 

1 . The submitter of the form is the complainant. The submitter should complete both its own contact information and, 
if the submitter is not a Participating DFI, contact information foritsDFI. 

2 . If you are a member of a Regional Payments Association, please specify the association to which you belong. 

3 . Please complete the sections relating to "ODFI," "RDFI," "Originator," or, if appropriate, "Other ACH Participant" 
as thoroughly as possible. 

Summary of Facts of Alleged Violation 

1. Please provide detailed information relating to the alleged rules violation by completing the section entitled 
"Description of Rules Violation." The Report must contain a description of the precise nature of the alleged rules 
violation, {he sequence of events involved, and the consequences resulting from the violation. The Report should 
specify the provision of the NACHA Operating Rules that is believed to have been violated and must provide 
information to identify the particular transaction (i.e., SEC Code, Transaction Code, Settlement Date, Dollar 
Amount, Trace Number, Account Number, and Date of Alleged Rules Violation). 

2. The Report must be accompanied by copies of all documents necessary to support the claim that a provision of the 
NACHA Operating Rules has been violated, including copies of relevant ACH entries (i.e., Company/Batch Header 
Records, Entry Detail Records, and Addenda Records, when applicable) and written communications between the 
complainant and the party against which the Report is being filed. 

Authorization for Submitting a Report of Possible ACH Rules Violation 

1. The Report must be signed by an officer of the complainant. 
Restrictions on Filing a Report of Possible ACH Rules Violation 

1. A Report of Possible ACH Rules Violation must be submitted to the National Association by the complainant within 
ninety (90) days of the occurrence of the alleged rules violation. 

2. In the event that the complainant is asserting that a rules violation has been committed by more than one 
Participating DFI, a separate Report of Possible ACH Rules Violation must be filed for each case. 

3. You must be a party to the transaction to submit a Report of Possible ACH Rules Violation. 
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COMPENSATION 



litigation can be tens of thousands of dollars, compared to 
several hundred dollars to file an arbitration claim. 

When the NA CHA Operating Rules are violated, one party 
is often forced to take on the additional burden and related 
costs of remedying the problem. Like other methods of 
dispute resolution, arbitration provides a mechanism for 
a DFI not only to identify a rule violation but also to be 
compensated for the damages caused to the DFI by such 
a violation. 



A. INTRODUCTION 




This chapter is designed to provide ACH participants with 
an understanding of the formal process, as prescribed by 
the NACHA Operating Rules, for the documentation and 
settlement of rules disputes through either the arbitration 
or the compensation process. These procedures exist, in 
conjunction with the national system of fines, to help to 
ensure compliance with the requirements of the NACHA 
Operating Rules and to ensure equitable treatment of 
ACH participants involved in disputes surrounding the 
processing of ACH transactions. 

B. ARBITRATION PROCEDURES 

In the late 1980s, the NACHA Operating Rules were 
amended to incorporate rules and procedures to address 
the settlement of disputes between Participating DFIs 
involved in an ACH transaction through the use of 
arbitration; Since these rules were implemented, the 
overall use of arbitration in the United States as a means 
of settling disputes has become more accepted and 
formalized. In 1999 and, more recently, in 2003, the 
NA CHA Operating Rules governing arbitration were 
revised and refined based on experience gained through 
the practical use of the arbitration process/These rules 
govern the submission of an arbitration case to the 
NACHA Arbitration Board. 

Arbitration provides a low-cost, expeditious mechanism 
for resolving disputes because it utilizes an evaluation and 
decision-making process involving experts in the ACH 
field. Many parties today are in favor of arbitration for a 
number of reasons. Arbitration provides an alternative to 
the resolution of an issue through litigation via the court 
system, which can be an extremely costly process, and, for 
cases in which the dollar amount of damages claimed is 
small, the cost of settling a dispute in such a manner may 
be prohibitive. Also, because court dockets today 
generally remain full, it may take years for a case to be 
heard and a judgment rendered. Morever, most judges are 
unaware of the NACHA Operating Rules, and educating 
a judge concerning the Rules in these instances may not be 
an efficient use of the court system. While the cost of 
bringing a case to court or to arbitration varies and 
depends on many factors, it is estimated that the minimum 
cost to a financial institution for the first phase of 



1. FILING A REQUEST FOR ARBITRATION 

To initiate an arbitration proceeding, the complainant (the 
Participating DFI) must submit a complaint to the 
National Association containing the following 
information: 

Identification of Parties 

The request for arbitration must include complete 
information to identify both the complainant and the other 
Participating DFI involved in the dispute. Required data 
includes the names, addresses, and telephone numbers of 
both parties. 

Summary of Facts 



The request for arbitration must contain a summary of the 
facts surrounding the dispute, including a description of 
the precise nature of the alleged rules violation(s). The 
request for arbitration must also specify the provision(s) 
of the NACHA Operating Rules alleged to have been 
violated, along with information permitting the 
identification of me particular transaction (i.e., Stand 
Entry Class Code, Settlement Date, Effective Entry Date, 
Dollar Amount, Trace Number, Date of Alleged Rules 
Violation, and Account Number). 

Statement of Damages 

The arbitration request must be accompanied by both a 
statement of the dollar amount of the damages claimed by 
the complainant as well as an explanation of how the 
damages claimed resulted from the alleged rules violation. 
The statement of damages claimed is not limited to the 
face value of the entry(ies) and may include costs related 
to handling the problem with the entry (i.e., the cost of the 
return, the cost of customer service, etc.), among other 
damages. 

Supporting Documentation 

The arbitration request must be accompanied by copies of 
all documents available to the complainant that are 
necessary to resolve the dispute, including copies of any 
written communications between the complainant and the 
Participating DFI against which the arbitration claim is 
being filed. 
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Application Fee 

The request for arbitration must be accompanied by a 
non-refundable application fee of $250. This fee will be 
used to cover administrative expenses relating to the 
processing of the arbitration claim. 

Authorization for Submitting a Request for Arbitration 

The request for arbitration must be signed by an officer of 
the complainant. 

Deadline for Filing 

A request for arbitration must be filed within two (2) years 
of the date of the violation(s) asserted. 

2. COMPLAINTS INVOLVING MULTIPLE 
PARTICIPATING DFIs 

In the event that the complainant is involved in related 
disputes with more than one Participating DFI, a separate 
request for arbitration must be filed with respect to each 
Participating DFI with which the complainant alleges a 
dispute. 

3. CLASSIFICATION OF DISPUTES 

Arbitration Procedure A - Complaints With Damages of 
$250 or More But Less Than $10,000 

All complaints in which the amount of damages claimed 
is $250 or more, but less than $ 10,000, must be processed 
under Arbitration Procedure A in accordance with the 
requirements of the NACHA Operating Rules,. 



Under the terms of Arbitration Procedure A, arbitration is 
mandatory for both parties once a claim for arbitration is 
filed. No hearing will be held, and one arbitrator will 
decide the case. The arbitrator's stipend will be $100. 

Arbitration Procedures- Complaints With Damages of 
$10,000 or More But Less Than $50,000 

All complaints in which the amount of damages claimed 
is $10,000 or more, but less than $50,000, must be 
processed under Arbitration Procedure B in accordance 
with the requirements of the NACHA Operating Rules. 

Under the terms of Arbitration Procedure B, arbitration is 
mandatory for both parties once a claim for arbitration is 
filed. No hearing will be held, and three arbitrators will 
decide the case. The stipend for each arbitrator will be 
1% of the arbitrator's decision. 

Arbitration Procedure C - Complaints With Damages 
of $50,000 or More 

All complaints in which the amount of damages claimed 
is $50,000 or more must be processed under Arbitration 



Procedure C in accordance with the requirements of the 
NACHA Operating Rules: 

Under the terms of Arbitration Procedure C, arbitration is 
not mandatory. Before a complaint is filed, both parties 
must agree to submit the dispute to arbitration. If both 
parties agree to arbitration, one of them must submit the 
complaint to the National Association. A hearing will be 
held unless the parties agree otherwise and notify the 
National Association at the time the complaint is filed. 
(Note: If both parties agree that a hearing will not be held, 
presentation of the case and the decision of the arbitrators 
will be governed by Arbitration Procedure B rather than 
Arbitration Procedure C.) If it so desires, a party may be 
represented at a hearing by legal counsel. Three 
arbitrators will decide the case. The stipend for each 
arbitrator will be 1.5% of the arbitrator's decision. 

4. SELECTION OF ARBITRATORS 

The National Association maintains a list of arbitrators 
that have been nominated by the NACHA membership 
and approved by the NACHA Board of Directors. 

Arbitration Procedure •L 

To select ah arbitrator for claims subject to Arbitration 
Procedure A, the National Association will mail each 
party to the dispute the same list of five arbitrators, chosen 
from among those appointed to the Arbitration Board, 
who are not affiliated with either party to the dispute. 
Each party must, within ten days of the date the list is 
mailed, review the list, delete two names, and mail or 
deliver the remaining names to the National Association. 
The National Association will compare the lists received 
from each party and select one arbitrator that has not been 
deleted from either list to decide the case. In the event 
that either list is not returned within the required time 
frame, the National Association will select the arbitrator 
to decide the case from among the names not deleted on 
the list returned, or, if neither list is returned within the 
required time limit, from among the names on the lists as 
mailed to each party. 

Arbitration Procedures B and C ■■'■ :■■■'■ 

To select an arbitrator for claims subject to Arbitration 
Procedures B and C, the National Association will mail 
each party to the dispute the same list of ten arbitrators, 
chosen from among those appointed to the Arbitration 
Board, who are not affiliated with either party to the 
dispute. Each party must, within ten days of the date the 
list is mailed, review the list, delete three names, and mail 
or deliver the remaining names to the National 
Association. The National Association will compare the 
lists received from each party and select three arbitrators 
that have not been deleted from either list to decide the 
case. In the event that either list is not returned within the 
required time frame, the National Association will select 
the arbitrators to decide the case from among the names 
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not deleted on the list returned, or, if neither list is 
returned within the required time limit, from among the 
names on the lists as mailed to each party. 



5. PRESENTATION OF THE CASE AND 
DECISION 

Arbitration Procedure A 




After a party has received notification of the selection of 
the arbitrator, it must, within fourteen days, provide to the 
National Association in writing any materials it believes 
appropriate for consideration in the case. The National 
Association will provide copies of such materials to both 
the arbitrator and to the other party to the dispute. In the 
event that the Participating DFI against which a request 
for arbitration has been filed fails to respond to the 
arbitrator's request for information within fourteen days 
of the arbitrator's request, the facts as stated in the 
arbitration complaint will be assumed to be true for 
purposes of the arbitration. 

Once the arbitrator has received all information that he 
believes is relevant or necessary to decide the case, the 
arbitrator will have thirty days to render his decision. 
Neither party may contact the arbitrator regarding the 
dispute unless the other party is present. The decision of 
the arbitration will be based upon the requirements of the 
NA CHA Operating Rules. The amount of any award of 
damages may not exceed the amount of damages claimed 
in the request for arbitration. 



The arbitrator is entitled to recover a part or all of the 
arbitrator's stipend from either party, as determined by the 
arbitrator. The arbitrator and each party to the dispute are 
responsible for their own expenses, including attorneys' 
fees, in connection with the arbitration process. 

Arbitration Procedure B 

After a party has received notification of the selection of 
the arbitrators, it will have fourteen days to submit to the 
National Association in writing any matter it deems 
appropriate for consideration in the arbitration 
proceeding. The National Association will submit copies 
of such materials to the arbitrators and to the other party. 
In the event that the respondent, in the judgment of the 
arbitrators, fails to cooperate in the proceeding within 
fourteen days of a request for information by the 
arbitrators, the facts as stated in the complaint will be 
assumed to be true for the purposes of the arbitration. 
Once the arbitrators have received all information they 
deem relevant or necessary, the arbitrators will have thirty 
days to render their decision. The amount of the award of 
damages may not exceed the amount of damages claimed 
in the complaint. The arbitrators may adopt rules and 
procedures with respect to evidence and other procedural 
and substantive matters not inconsistent with the NA CHA 
Operating Rules as they deem appropriate. The decision 
of the arbitrators will be based upon the NACHA 



Operating Rules insofar as they are applicable. Neither 
party may initiate contact with the arbitrators concerning 
the dispute unless the other party is present. The 
arbitrators are entitled to recover a part or all of the 
arbitrators' stipend from either party, as determined by the 
arbitrators. The arbitrators will pay their expenses, and 
each party will pay its own expenses, including attorneys' 
fees, in connection with the arbitration. 

Arbitration Procedure C 

If a hearing is to be held, the arbitrators will set a hearing 
date for at least ninety days after each party has received 
notification of the selection of the arbitrators. The 
National Association will provide both parties with notice 
of the hearing at least thirty days prior to the scheduled 
date of the hearing. Following the hearing, the arbitrators 
will have thirty days to render their decision on the case. 
The amount of any award of damages may not exceed the 
amount of damages claimed in the complaint. The 
arbitrators may adopt rules and procedures with respect to 
evidence and other procedural and substantive matters not 
inconsistent with the NACHA Operating Rules as they 
deem appropriate. The decision of the arbitrators will be 
based on the NA CHA Operating Rules insofar as they are 
applicable/Neither party may initiate contact with any 
arbitrator concerning the subj ect matter of the dispute 
unless the other party is present. Each party will pay its 
own expenses, including attorneys' fees, in connection 
with the arbitration. The arbitrators are entitled to recover 
a part or all of their travel and other expenses in 
connection with the arbitration proceeding and the 
arbitrators' stipend from either party, as determined by the 
arbitrators. 

6. PAYMENT AND APPEAL OF DECISION 

Arbitration Procedures AandB 

The party against which damages have been assessed by 
the arbitrator(s) must pay the damage award or other 
amount assessed against it within fourteen days after 
receipt of the notice of the decision. The decision of the 
arbitrator(s) is final and binding on the parties to the 
dispute, and the judgment may be entered into any court 
having jurisdiction. Except where unlawful under the 
laws of the state in which the party against which damages 
have been assessed by the arbitrator is domiciled, the 
arbitrator's decision may not be appealed to the courts. 

Arbitration Procedure C 

In the absence of an appeal to the courts, the party against 
which damages have been assessed by the arbitrators must 
pay the damage award or other amount assessed against it 
within fourteen days after receipt of the notice of the 
decision. The arbitrators' decision is binding on the 
parties to the dispute and the judgment may be entered 
into any court having jurisdiction. Except where the 
parties have entered into an enforceable agreement to the 
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contrary, either party may appeal the arbitrators' decision 
to the courts. In the absence of such an appeal, the 
arbitrators' decision will be final 

7. NACHA ARBITRATION BOARD 

Criteria for Nomination 

Because of the nature of the disputes that an arbitrator 
may be called upon to settle, it is critical that nominees to 
the National Association's Arbitration Board possess a 
number of specific qualifications: 



* Knowledge of ACH Rules and Regulations 

Arbitrators are expected to have a superior command 
of the rules, regulations, and processing requirements 
governing the AGH Network, as well as a thorough 
understanding of and experience with general 
banking practices and procedures. 

Arbitrators who hold the Accredited ACH 
Professional (AAP) credential or who are attorneys 
with knowledge of and experience in electronic 
payments processing are preferred. 

•■ Work Experience 

Arbitrators should be professionals from banking and 
banking-related industries with at least two years' 
work experience in ACH payments. 

Responsibilities of Arbitrators 

The position of arbitrator is a voluntary position. 
Arbitrators serve for a three-year term of service. The 
arbitrator is responsible for reviewing all materials 
presented to support a case and for rendering a decision in 
accordance with ih.Q NACHA Operating Rules: An 
arbitrator may also be required to appear at an arbitration 
hearing when Arbitration Procedure B is utilized. 
Arbitrators are entitled to a stipend, as established by the 
NACHA Operating Rules, for their services. 

C. COMPENSATION 



In the late 1980s, the NACHA Operating Rules were 
amended to incorporate a set of rules and procedures used 
to determine compensation between Participating DFIs for 
the loss of use of funds in specific situations. These rules 
are used to ensure that one Participating DFI is not 
excessively enriched or injured as the result of an error 
made by another Participating DFI. The compensation 
rules governing ACH payments were initially developed 
based upon the compensation rules developed and 
maintained by the National Council for Uniform Interest 
Compensation (N.C.U.LC.) for check and wire transfer 
transactions. 



1. SCOPE OF COMPENSATION RULES 

These rules are used between Participating DFIs to settle 
claims for compensation that may arise due to errors made 
during the course of ACH processing, such as the failure 
of a payment to be transmitted on schedule, the 
transmission of a payment to an incorrect account or to an 
incorrect Participating DFI, or the transmission of a 
duplicate entry. The compensation rules for ACH 
payments provide a mechanism for adjusting the value of 
the funds so that neither the ODFI nor the RDFI is 
unjustly injured as a result of these types of errors: 

Not every possible scenario concerning a compensation 
claim is explicitly addressed by the NACHA Operating 
Rules. In circumstances in which a valid claim for 
compensation is not addressed by the rules, Participating 
DFIs are expected to settle the claim so that neither 
Participating DFI is unjustly enriched or injured. 

Most Common Uses For Compensation 

•■ Failure to Transmit an ACH Payment 

Most commonly referred to as a late payment, this 
type of processing error occurs most frequently. In 
general, two instances give rise to this type of error 
by Participating DFIs: (1) failure to transmit the 
payment to effect settlement on the agreed upon date; 
or (2) transmission of an amount less than agreed 
upon. 

•/■' Payment Transmitted in Error 

These types of processing errors generally include 
duplicate payments, over-payments, payments 
transmitted too early, and missent payments. 

• Incorrect Receiver 

In this type of error, funds are transmitted to the 
correct Participating DFI but to the wrong Receiver. 

For specific information on calculating compensation for 
each of these types of errors, please refer to the 
Compensation chapter within the NA CHA Operating 
Rules. 



2. '■ MINIMUM CLAIM AMOUNT FOR 
COMPENSATION 

A claim for compensation may be filed under these rules 
only if the loss suffered by the claimant with respect to a 
particular entry is at least $200. The amount of loss 
suffered by the Participating DFI is calculated based upon 
the equations contained within the NACHA Operating 
Rules. The amount of loss calculated will exclude an 
administrative fee of $200 per entry, which is added to or 
subtracted from the calculation, and will include any 
applicable Deposit Insurance Assessment. 
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3. DEPOSIT INSURANCE ASSESSMENTS 

A Deposit Insurance Assessment is the amount of 
increase, if any, in the insurance premium required to be 
paid by the financial institution because the relevant entry 
increased the amount of deposits upon which the 
insurance premium is calculated. A Deposit Insurance 
Assessment may be calculated for Federal Deposit 
Insurance Corporation (FDIC) premiums, or, in the case 
of credit unions, for National Credit Union Share 
Insurance Fund (NCUSIF) premiums. For credit unions, 
the Deposit Insurance Assessment also includes the 
increase, if any, in the amount of deposits required to be 
maintained by the RDFI with the NCUSIF because the 
relevant entry increased the base upon which the deposits 
required to be maintained is calculated. 
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mapping;;^^;^^^^;;: :; ;; 

A. INTRODUCTION . ';' 

This chapter is designed to assist ACH participants in 
properly formatting transaction information. The ACH 
Format Specifications in the NACHA Operating Rules 
detail the contents of the various record formats and 
define the code values and data elements. This chapter 
presents two sample ACH applications and illustrates how 
the relevant information is "mapped" to the ACH formats. 

The sample applications consist of a payroll application (a 
batch of consumer credit entries) and a monthly dues 
application (a batch of consumer debit entries). Based on 
the sample applications and certain assumptions, this 
chapter will illustrate how the PPD ACH records are 
formatted. 

The basic record sequence for ACH files is found below. 
For more information on mapping corporate payment 
formats, contact NACHA, 13665 Dulles Technology 
Drive, Herndon, VA 20171, (703) 561-1100. 



File Hftsoof Rocofd 



File Control Record 



ACH Trailer Label Records) 



Diagram of File Sequence 

The records in the previous diagram are illustrated in this 
chapter as follows: 

File Header and File Control Records : 

Because the same ODFI is originating both applications, 
the File Header and File Control Records will contain the 
appropriate information for both applications (batches) to 
be included in the same file. 



Batch Header and Batch Control Records: 



For Application #1, the payroll application, these records 
introduce and summarize the first batch in the file. 

Entry Detail Records : 

For Application #1 , the payroll application, these records 
contain information about the individuals being paid. 

Batch Header and Batch Control Records : 

For Application #2, the monthly dues application, these 
records introduce and summarize the second batch in the 
file.'- : :' ; :' : -' 



Entry Detail Records : 

For Application #2, the monthly dues application, these 
records contain information about the individuals being 
charged. 
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Following the illustration of the origination of both of 
these applications, this chapter also illustrates how an 
RDFI would originate returns and notifications of change, 
how an ODFI would initiate dishonored returns and 
refused notifications of change, and finally, how an RDFI 
would originate a contested dishonored return. 

B. SAMPLE APPLICATIONS AND 
ASSUMPTIONS 

ABC Trust has just begun originating ACH payments and 
pre sentry has two originating customers : 

Application #1 

VLS, Inc. pays its employees monthly via direct deposit. 
On June 25, VLS, Inc. prepares an ACH file on its PC 
software package for delivery to ABC Trust. The file 
contains the information for the pay date of June 27. 
Three individuals are being paid a total of $30,000. 
VLS's payroll information is listed below: 



NAME 


McGowan, Grace 


MEMBERSHIP # 


3918 


DUES 


$200.00 


FI . : 


DEFBank 


RTN 


12391871 


AGCT.# 


19650-54 32 6 (checking) 


NAME ' 


Miller, Rob 


MEMBERSHIP # 


3977 


DUES 


$200.00 


FI 


PQRS&L 


RTN 


07777777 


ACCT.# 


76 432 212-1799 (checking) 


NAME 


Danelli, Jack 


MEMBERSHIP # 


3913 


DUES 


$200.00 


FI 


XYZGU. 


RTN 


08888888 


ACCT. # 


453596 8-61-43 (checking) 



NAME 

EMPLOYEE ID 
NET PAY 
FI 



Watson, Ben 
565-65-6565 
$10,000.00 
JKLS&L 



K 1 IN 

ACCT.# 


12-345 678 (checking) 


NAME 


Davis, Janet 


EMPLOYEE ID 


911-91-1911 


NET PAY 


$10,000.00 


FI 


MNOC.U. 


RTN 


21777777 


ACCT.# .;...;... 


98765432121 (savings) 


NAME 


Zark, Matt 


EMPLOYEE ID 


121-12-1212 



NET PAY 
FI 

RTN 
ACCT. # 



$10,000.00 

DEFBank 

12391871 

5 56 8-65 47 (checking) 



VLS's ID number is a user assigned number - 1 1 1 1 11119. 

Application #2 

UVW Club collects some of its monthly dues via ACH 
debit. On June 25, UVW Club prepares an ACH file on 
its PC software package and delivers it to ABC Trust via 
modem. The file contains three collections for July dues. 
The entries total $600.00. 



ABC Trust's ID (Routing and ABA Number) is 05999999. 

ABC Trust receives the information from its two 
Originators and prepares a file for delivery to its ACH 
Operator - TCB Services. TCB Services' Routing 
Number is 05 1 00003 . The file contains one batch of 
credits and one batch of debits. Each batch carries three 
PPD entries. The file, batch, and entry level records, as 
prepared by ABC Trust for delivery to the ACH Operator, 
are shown below, Note: The timing of our example 
transactions will be affected by a weekend (June 30 & 
July 1) and a Federal Government holiday (July 4). 

C. ACH FILE FROM ODFI TO ACH OPERATOR 

Once the ODFI has received the batches from its 
Originators, the ODFI prepares a file for delivery to the 
ACH Operator. All of the record layouts below illustrate 
how information is mapped into the record by example. 
Illustrations relate to the specific applications outlined 
above and are not intended to depict situations which will 
always be appropriate. 




UVW's ID number is its tax ID - 047777779. UVW 
Club's customer information is listed below: 
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FILE HEADER RECORD 



FIELD 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


DATA 

ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


PRIORTTY 

CODE 


IMMEDIATE 

DESTINATION 


IMMEDIATE 
ORIGIN 


RLE 

CREATION 

DATE 


FILE 
CREATION 

TIME 


FILE ID 
MODIFIER 


RECORD 
SIZE 


BLOCKING 
FACTOR 


FORMAT 
CODE 


IMMEDIATE 

DESTINATION 

NAME 


IMMEDIATE 
ORIGIN 

NAME 


REFERENCE 
CODE 


Field 

Inclusion 

Requirement 


M 


R 


M 


M 


\ M 


O 


M 


M 


M 


M 


O 





O 


Contents 


T 


Numeric 


bTTTTAAAAC 


bTTTTAAAAC 


YYMMDD 


HHMM 


UPPER 

CASEA-Z 

NUMERIC 

0-9 


■094- 


'10 


■ -'1' 


Alphameric 


Alphameric 


Alphameric 


Length 


1 


2 


10 


10 


6 


4 


1 


3 


2 


1 


23 


23 


8 


Position 


01-01 


02-03 


04-13 


14-23 


24-29 


30-33 


34-34 


35-37 


38-39 


4040 


41-63 


64-66 


87-94 




Example 


1 


01 


051000033 


0699999997 


90C625 


2030 


A ■■'■ 


094 


10 


1 


TCB SERVICES 


ABC TRUST 





File Header Record - Original Entry 

The File Header Record introduces the file. It designates 
physical file characteristics and identifies the sender of the 
file (the ODFI) and the party to which the file is being 
delivered (the ACH Operator). In addition, this record 
includes the date, time, and file identification fields which 
can be used to identify a particular file. 

Key Fields: 

Immediate Destination 

The Immediate Destination field identifies the party to 
which the file is being delivered. It contains the Routing 
Number of the ACH Operator - TCB Services. 

Immediate Origin 

The Immediate Origin field identifies the sender of the 
file. It contains the Routing Number of the ODFI - ABC 
Trust. 



File Creation Date and File Creation Time 



The File Creation Date is ■ 900625', the date on which the 
file is prepared by ABC Trust. The File Creation Time is 
"2030*. The File Creation Time is the time in hours and 
minutes that the creation or exchange took place. 

File ID Modifier 

The File ID Modifier is ■ A ■ because it is the first file that 
ABC Trust is delivering to the ACH Operator on June 25. 
Subsequent files, if any, would be labeled "B 1 , C\ etc. 
The File ID Modifier, coupled with the File Creation Date 
and Time, can be used by the ODFI, along with other 
information, to trace the file. 
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COMPANY/BATCH HEADER RECORD 


FIELD 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


DATA 
ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


SERVICE 
CLASS 
CODE 


COMPANY 
NAME 


COMPANY 

DISCRETIONARY 

DATA 


COMPANY 
IDENTIFICATION 


STANDARD 
ENTRY 
CLASS 
CODE 


COMPANY 

ENTRY 

DESCRIPTION 


COMPANY 

DESCRIPTIVE 

DATE 


EFFECTIVE 
ENTRY 
DATE 


SETTLEMENT 

DATE 

(JULIAN) 


ORIGINATOR 
STATUS 
CODE 


ORIGINATING 

DFI 

IDENTIFICATION 


BATCH 
NUMBER 


Field 

Inclusion 

Requirement 


M 


M 


M 





. M . . 


M 


M 


o 


R 


Inserted by 
ACH Operator 


M 


M ■ 


M 


Contents 


'5* 


Numeric 


Alphameric 


Alphameric 


Alphameric 


Alphameric 


Alphameric 


Alphameric * 


YYMMDD 


Numeric 


Alphameric 


TTTTAAAA 


Numeric 


Length 


1 


3 


16 


20 


10 


3 


10 


6 


6 


3 


1 . ; 


8 . 


■ 7 . ■ 


Position 


01-01 


02-04 


05-20 


21-40 


41-50 


51-53 


54-63 


64-69 


70-75 


76-78 


79-79 


80-87 


88-94 






Example 


5 


220 


VLS INC 


DIRECT DEPOSIT 


9111111119 


PPD 


DIRECT PAY 


062590 


. 900627 




1 


05999999 


0000001 




Company/Batch Header Record 

The first Company/Batch Header Record introduces the 
first application. It also identifies the Originator of the 
application and briefly describes the application. 

Key Fields: 

Company Identification 

The Company Identification field carries the Originator's 
unique identification number. ANSI one-digit 
Identification Code Designators (ICD) are used, followed - 
by the nine-digit identification number. In this example; 
the Company ID field contains a user assigned number, 
111111119V 

Standard Entry Class (SEC) Code 

The SEC code distinguishes the various types of ACH 
entries. In our example, the SEC code is TPD', 
prearranged payment and deposit entries Use of this code 
identifies the entries as consumer entries, i.e., going to a 
consumer's account. The responsibilities of the RDFI also 
relate to this code. 



Company Entry Description 

The Company Entry Description provides a description of 
the entry that is displayed on the consumer's statement 
when the payment is posted. VLS, Inc. has chosen 
* DIRECT PAY* to describe its application. 

Effective Entry Date 

The Effective Entry Date is the date specified by the 
Originator as the day on which its employees should be 
paid. 

Settlement Date 

The Settlement Date (Julian Date) is the date on which the 
ODFI and RDFI are debited or credited by the Federal 
Reserve. 

The settlement date is inserted by the Receiving ACH 
Operator and therefore is blank on this example. 

Assuming that this file is delivered appropriately, either 
on June 25 or June 26, the Settlement Date for this batch 
would be "177", the Julian Date equivalent for June 27. 

Originating DFI Identification 

The Originating DFI Identification field carries ABC 
Trust's Routing Number - v 05999999\ 
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ENTRY DETAIL RECORDS 


FIELD 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


DATA 

ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


TRANSACTION 
CODE 


RECEIVING DFI 
IDENTIFICATION 


CHECK 
DIGIT 


DFI ACCOUNT 
NUMBER 


AMOUNT 


INDIVIDUAL 
IDENTIFICATION 

NUMBER 


INDIVIDUAL NAME 


DISCRETIONARY 
DATA 


ADDENDA 
RECORD 
INDICATOR 


TRACE 
NUMBER 


Field 

Inclusion 

Requirement 


M 


M 


.-.'..' m . : 


M 


R 


M 


O 


R 





M 


M ... 


Contents 


■6' 


Numeric 


TTTTAMA 


Numeric 


Alphameric 


$$$$$$$$$£ 


Alphameric 


Alphameric 


Alphameric 


Numeric 


Numeric 


Length 


1 


2 


8 


1 


17 


10 


15 


22 


2 


1 


15 


Position 


01-01 


02-03 


04-11 


12-12 


13-29 


30-39 


40-54 


55-76 


77-78 


79-79 


80-94 




Example 


6 


22 


21433433 


9 


12-345678 


0001000000 


565-65-6565 


BEN WATSON 


01 





05999999 
0000001 




Example 


6 


32 


21777777 


3 


9876543212 


0001000000 


911-91-1911 


JANET DAVIS 


01 





05999999 
0000002 




Example 


6 


22 


12391871 





5568-6547 


0001000000 


121-12-1212 


MATTZARK 


01 





05999999 
0000003 



Entry Detail Records 

The Entry Detail Record contains information about the 
Receiver and the Receiver's financial institution. 

Key Fields: 

Transaction Code 

The Transaction Code is used to t direct the payment to a 
specific type of account, i.e. checking or savings, and 
indicates whether the payment is a deposit (credit) or 
withdrawal (debit). 

Receiving DFI Identification 



The Receiving DFI Identification is the Routing Number 
of the DFI where the employee maintains an account. The 
three examples reflect different Routing Numbers in the 
Receiving DFI Identification fields because each 
employee maintains an account at a different financial 
institution. 

DFI Account Number 

The DFI Account Number field contains the RDFI's 
customer identification (account number). Note how the 
DFI Account Number has been formatted in the sample 
entries (spaces have been eliminated). 



Amount 

The Amount field contains the dollar amount of the entry. 

Individual Name 

The Individual Name field contains the name of the 
Receiver. This provides additional identification and may 
be helpful to the Originator in identifying returned entries. 
Notice the information carried in the Individual Name 
fields of the examples. 

Trace Number 

The Trace Number is assigned by the ODFI in ascending 
sequence and uniquely identifies each entry within a 
batch. Note that the first eight digits of the Trace Number 
are always the Routing Number of the ODFI. In 
association with the File Creation Date, File ID Modifier, 
and other information, the Trace Number can be used to 
trace an entry through the ACH Network. 

Throughout the entire processing cycle (from ODFI to 
RDFI), the Trace Number is retained with the entry 
record. The Trace Number is critical in routing return 
entries and notifications of change from the RDFI back to 
the ODFI through the ACH Network. 
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COMPANY/BATCH CONTROL RECORD 



FIELD 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


DATA 

ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


SERVICE 
CLASS 
CODE 


ENTRY/ 

ADDENDA 

COUNT 


ENTRY 
HASH 


TOTAL DEBIT 
ENTRY DOLLAR 

AMOUNT 


TOTAL CREDIT 

ENTRY DOLLAR 

AMOUNT 


COMPANY 

IDENTIFICATION 


MESSAGE 

AUTHENTICATION 

CODE 


RESERVED 


ORIGINATING 

DFI 

IDENTIFICATION 


BATCH 
NUMBER 


Field 

Inclusion 

Requirement 


M 


M 


M 


M 


M 


M 


R 


o 


N/A 


M 


. . M 


Contents 


'8' 


Numeric 


Numeric 


Numeric 


$$$$$$$$$$## 


$$$$$$$$$$** : 


Alphameric 


Alphameric 


Blank 


TTTTAAAA 


Numeric 


Length 


1 


3 


6 


10 


12 


12 


10 


19 


6 


8 


7 


Position 


01-01 


02-04 


05-10 


11-20 


21-32 


33-44 


45-54 


55-73 


74-79 


80-87 


88-94 



Example 


8 


220 


000003 


0055603081 


000000000000 


000003000000 


9111111119 






05999999 


0000001 




Company/Batch Control Record 

The Company/Batch Control Record summarizes the 
information contained in the batch. It contains the counts, 
hash totals, and total dollar controls for the preceding 
detail entries within the batch. 

Key Fields: 



Entry/Addenda Count 

The Entry/Addenda Count field is a tally of each Entry 
Detail and Addenda Record processed within the batch. 
No addenda records were used in this application, as 
indicated by the information in this field. 

Entry Hash 

This field is prepared by hashing the critical Routing 
Number in each entry. The Entry Hash provides a check 
against inadvertent alteration of data contents due to 
hardware or program failure. 



Total Debit & Credit Entry Dollar Amounts 

The Total Debit & Credit Entry Dollar Amount fields 
contain accumulated Entry Detail debit and credit totals 
within a given batch. In our example, the Total Credit 
Entry Dollar Amount is $30,000, and the Total Debit 
Entry Dollar Amount is zero because no debits were 
originated within the batch. 

Company Identification 

This field carries the same information that is carried in 
the Company Identification field of the Company/Batch 
Header Record. 

Originating DFI Identification 

The Originating DFI Identification carries the same 
information that is carried in the Originating DFI 
Identification field of the Company/Batch Header Record. 
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COMPANY/BATCH HEADER RECORD 



FIELD 


1 


2 


3 


4 


5 


6 


■ ■ 7. 


8 


9 


10 


11 


12 


13 


DATA 

ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


SERVICE 
CLASS 
CODE 


COMPANY 
NAME 


COMPANY 
DISCRE- 
TIONARY 
DATA 


COMPANY 

IDENTIFI- 
CATION 


STANDARD 
ENTRY 
CLASS 
CODE 


COMPANY 

ENTRY 

DESCRIPTION 


COMPANY 
DESCRIP- 
TIVE 
DATE 


EFFECTIVE 
ENTRY 
DATE 


SETTLEMENT 

DATE 

(JULIAN) 


ORIGINATOR 
STATUS 
CODE 


ORIGINATING 
DFI 
IDENTIFI- 
CATION 


BATCH 

NUMBER 


Field 

Inclusion 

Requirement 


: m ■ .' 


M 


M 


O 


M 


M 


M 


O 


R 


Inserted by 
ACH Operator 


M 


M 


M 


Contents 


'5' 


Numeric 


Alphameric 


Alphameric 


Alphameric 


Alphameric 


Alphameric 


Alphameric 


YYMMDD 


Numeric 


Alphameric 


TTTTAAAA 


Numeric 


Length 


1 . 


3 


16 


20 


10 


3 


10 


6 


6 


3 


1 '■' 


8 


7 


Position 


01-01 


02-04 


05-20 


21-40 


41-50 


51-53 


54-63 


64-69 


70-75 


76-78 


79-79 


80-87 


88-94 



Example 


5 


225 


UVW 
CLUB 


DUES 


1047777779 


PPD 


MONTH-DUES 


062590 


900626 




. .1 : : 


05999999 


0000002 































Company/Batch Header Record 

The second Company/Batch Header Record introduces 
the second application: As in the first Company/Batch 
Header Record, it also identifies the Originator of the 
application and briefly describes the application. 



Because the batch contains debit entries, the effective date 
for this batch is June 2.6, 1990. The key fields are the 
same, and, as shown by example above, information 
specific to the Originator and the application are mapped 
into the record layout. 



ENTRY DETAIL RECORDS 



FIELD 


1 


2 


3 


4 


5 ■'.-.■■ 


6 


7 


8 


9 


10 


11 


DATA 
ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


TRANS- 
ACTION 
CODE 


RECEIVING DFI 
IDENTIFICATION 


CHECK 
DIGIT 


DFIACCOUNT 
NUMBER 


AMOUNT 


INDIVIDUAL 

IDENTIFICATION 

NUMBER 


INDIVIDUAL NAME 


DISCRE- 

TIONARY 
DATA 


ADDENDA 
RECORD 
INDICATOR 


TRACE 

NUMBER 


Field 

Inclusion 

Requirement 


M 


M 


M 


M 


■ ■ R ' ■ 


M 


'.'■'.'. o ".■':'■ ' 


.■ R. V 





M 


. M 


Contents 


■6* 


Numeric 


TTTTAAAA 


Numeric 


Alphameric 


$$$$$$$$^ 


Alphameric 


Alphameric 


Alphameric 


Numeric 


Numeric 


Length 


1 


■ .-.2. ■';.-.' 


8 . 


■ 1 ■:■■:■ 


17 


10 


15 


22 


2 


1 


15 


Position 


01-01 


02-03 


04-11 


12-12 


13-29 


30-39 


40-54 


55-76 


77-78 


79-79 


80-94 



Example 


6 


27 


12391871 





19650-54326 


0000020000 


3918 


GRACE McGOWAN 


07 





05999999 
0000301 



76432212-1799 



3999 
302 | 



Example 


6 


27 


08888888 


8 


4535968-61-43 


0000020000 


3913 


JACK DANELLI 


07 





05999999 
0000303 



Entry Detail Records 

For the second application, the information regarding the 
individuals that owe monthly dues is placed in the Entry 
Detail Records, as portrayed on the previous page. 



The key fields are the same as for the Entry Detail 
Records in the first application. 
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COMPANY/BATCH CONTROL RECORD 



FIELD 


1 


2 


3 


4 


■'.'■ ■ 5 . ■ 


6 


7 


8 


9 


10 


11 


DATA 

ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


SERVICE 
CLASS 
CODE 


ENTRY/ 

ADDENDA 

COUNT 


ENTRY 
HASH 


TOTAL DEBIT 
ENTRY DOLLAR 

AMOUNT 


TOTAL CREDIT 

ENTRY DOLLAR 

AMOUNT 


COMPANY 

IDENTIFI- 
CATION 


MESSAGE 

AUTHENTICATION 

CODE 


RESERVED 


ORIGINATING 

DFI 

IDENTIFI- 

CATION 


BATCH 

NUMBER 


Field 

Inclusion 

Requirement 


M 


. .'■ M 


M 


M 


M 


M 


R 





N/A 


M 


M 


Contents 


'8* 


Numeric 


Numeric 


Numeric 


$$$$$$$$$$00 


$$$$$$$$$$00 


Alphameric 


Alphameric 


Blank 


TTTTAAAA 


Numeric 


Length 


: i ■'. 


3 


6 ■'.■ 


10 


12 


12 


10 


19 


6 


8 


7 ■' 


Position 


01-01 


02-04 


05-10 


11-20 


21-32 


33-44 


45-54 


55-73 


74-79 


80-87 


88-94 




Example 


8 


225 


000003 


0029058536 


000000060000 


000000000000 


1047777779 






05999999 


0000002 



Company/Batch Control Record 

As in the first application, the Company/Batch Control 
Record summarizes the information contained in the 
batch. The key fields are the same. 




FILE CONTROL RECORD 




FIELD 


1 


. ... 2 '■ 


3 


.' 4 


s 


■ . 6' 


■'■'■; 7 


'■'■■ ■'■*'.::■ '■ 


DATA 

ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


BATCH 

COUNT 


BLOCK 

COUNT 


ENTRY/ 

ADDENDA 

COUNT 


ENTRY HASH 


TOTAL DEBIT 
ENTRY DOLLAR 

AMOUNT IN FILE 


TOTAL CREDIT 
ENTRY DOLLAR 
AMOUNT IN FILE 


RESERVED 


Held 

inclusion 

Requirement 


M 


■ . M ■' '■ 


M 


■ '. M .V.' ■ 


M 


M 


M 


N/A 


Contents 


'9' 


Numeric 


Numeric 


Numeric 


Numeric 


■ $$$$$$$$$$<(? 


$$$$$$$$$$$0 


Blank 


Length 


■.-.'■ - 1 ■.■■' ■ 


■''..■. 6 . 


,'.■■'■:■ 6 ■;■'. '■ 


■ ' 8 


10 


■'.■:■.-. 12 , : . 


.■'■■■■ 12 ■';■ \ 


: : ' 39 ■;'.'■ 


Position 


01-01 


02-07 


08-13 


14-21 


22-31 


32-43 


44-55 


56-94 










Example 


■'■'■' 9 


■' ■' : ■ ' ■ 000002 


000002 


00000006 


0OB4661617 


000000060000 


000003000000 





File Control Record 

The File Control Record summarizes the information 
carried in the Company/Batch Control Records. It 
contains dollar, entry, and hash total accumulations from 
the Company/Batch Control Records in the file. This 
record also contains counts of the number of blocks and 
the number of batches within the file. 



Key Fields: 



Batch Count 



The value of the Batch Count field is equal to the number 
of Company/Batch Header Records in the file. In this 
example, the value is 2. 
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Entry Hash 

This field is prepared by hashing the critical Routing 
Number in each entry. The Entry Hash provides a check 
against inadvertent alteration of data contents due to 
hardware or program failure. 

Total Debit & Credit Dollar Amount In File 

The Total Debit & Credit Entry Dollar Amounts fields 
contain accumulated Entry Detail debit and credit totals 
within the file. In our example, the Total Debit Entry 
Dollar Amount is $600.00, and the Total Credit Entry 
Dollar Amount is $30,000. 



D. 



RETURN AND NOTIFICATION OF CHANGE 
. ENTRIES 




This section will illustrate how return and notification of 
change entries are prepared. The example application 
will show the preparation of a file which contains two 
batches. The first batch carries a single return entry, and 
the second batch contains a single notification of change 
entry. 



Additional Information 
Change Entries 



Return and Notification of 



The original entries are received by the RDFIs, but DEF 
Bank (Routing Number 12391871) cannot post the 
$200.00 entry for Grace McGowan (account '# 1 9650-54 
3.2 6) because her account does not have sufficient funds 
to cover the debit (return reason code R01). 

The DEF Bank also prepares a notification of change to 
notify ABC Trust (the ODFI) that the DFI Account 
Number for Matt Zark is incorrect and should be changed. 
The Original Entry carried a DFI Account Number of 
5568-6547, but the correct DFI Account Number is 68- 

6547. 

DEF's ACH Operator has a Routing Number of 
12001000. 



FILE HE ADER RECORD - RETURN AND NOTIFICATION OF CHANGE ENTRIES 


FIELD 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


DATA 

ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


PRIORITY 
CODE 


IMMEDIATE 
DESTINATION 


IMMEDIATE 
ORIGIN 


FILE 

CREATION 

DATE 


FILE 

CREATION 
TIME 


FILE ID 
MODIFIER 


RECORD 
SIZE 


BLOCKING 
FACTOR 


FORMAT 
CODE 


IMMEDIATE 

DESTINATION 

NAME 


IMMEDIATE 
ORIGIN 
NAME 


REFERENCE 
CODE 


Field 

Inclusion 

Requirement 


M . . 


R 


.M 


.'■' . M . 


M 


O 


M 


M 


M 


M 


'■'■O'- 


O 


o 


Contents 


T 


Numeric 


bTTTTAAAAC 


bTTTTAAAAC 


YYMMDD 


HHMM 


UPPER 

CASE A-2 

NUMERIC 

0-9 


'094' 


'10' 


'V 


Alphameric 


Alphameric 


Alphameric 


Length 


1 


2 


10 


10 


: ■ 6 ■ 


4 


1 


3 


2 


.'■■1 ' 


23 


23 


8 


Position 


01-01 


02-03 


04-13 


14-23 


24-29 


30-33 


34-34 


35-37 


38-39 


40-40 


41-63 


64-86 


87-94 




Example 


1 


01 


120010006 


123918710 


900628 


2015 


A 


094 


10 


1 


FMP SERVICES 


DEF BANK 





File Header Record 
Entries , 



Return and Notification of Change 



In these applications, the RDFI of the original entries is 
the ODFI of the return and notification of change entries, 
and the ODFI of the original entries is the RDFI of the 
return and notification of change entries. The File Header 
Record for return and notification of change applications 
is illustrated above. 



This file is prepared in a manner similar to the file 
containing the original entries. 

For more information on how the file is created, see the 
NA CHA Operating Rules and the File Header Record 
layouts prepared above in the original entry section 
(section C). 
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COMPANY/BATCH HEADER RECORD - RETURN ENTRY 



FIELD 


1 


2 


■'■'.' 3 


4 


5 .'.■ 


6 


7 


8 


9 


10 


■ .'. ■ 11 


12 


13 


DATA 
ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


SERVICE 
CLASS 
CODE 


COMPANY 

NAME 


COMPANY 

DISCRETIONARY 

DATA 


COMPANY 
IDENTIFI- 
CATION 


STANDARD 

ENTRY 
CLASS 
CODE 


COMPANY 

ENTRY 

DESCRIPTION 


COMPANY 

DESCRIPTIVE 

DATE 


EFFECTIVE 
ENTRY 
DATE 


SETTLEMENT 
DATE 

(JULIAN) 


ORIGINATOR 
STATUS 
CODE 


ORIGINATING 

DFI 

IDENTIFI- 

CATION 


BATCH 
NUMBER 


Field 

Inclusion 

Requirement 


M 


M 


M 


O 


M 


M 


M 


O 


R 


Inserted by 
ACH Operator 


M 


M 


M 


Contents 


'5' 


. 1 
Numeric 


Alphameric 


Alphameric 


Alphameric 


2 
Afphameric 


3 
Alphameric 


Alphameric 


YYMMDD 


Numeric 


Alphameric 


■ . '■ ■ 5 
TTTTAAAA 


6 
Numeric 


Length 


1 


3 


16 


20 


10 


3 


10 


6 . 


. . 6 ■ 


■ '■'.'. 3 . 


■ '1 ■' ■ 


8 


7 


Position 


01-01 


02-04 


05-20 


21-40 


41-50 


51-53 


54-63 


64-69 


70-75 


76-78 


79-79 


80-87 


88-94 



Example 


5 


225 


UVW CLUB 


DUES 


1047777779 


PPD 


MONTH-DUES 


062590 


900626 




1 


12391871 


0000001 



Company/Batch Header Record - Return Entry 

The Company/Batch Header Record layout containing a 
sample Return Entry is shown above. Note: All fields are 
the same as they were in the Company/Batch Header of 
the original entry unless otherwise noted. 

The fields containing information different from the 
original entry are shown below: 

Originator Status Code 

The Originator Status Code is changed to reflect the status 
of the institution initiating me Return Entry (the RDFI of 
the original entry). 



In this example, the Originator Status Code is T for the 
Return Entry as well as the Original Entry. 

Originating DFI Identification 

The Originating DFI Identification is changed to the 
Routing Number of the institution initiating the Return 
Entry (the RDFI of the original entry). In this example, 
the Originating DFI Identification field carries DEF 
Bank's Routing Number - , 12391 871'. 

Batch Number 

The Batch Number field carries the number assigned by 
the institution preparing the Return Entry. The Batch 
Number in this example is '000000 1'. 




ENTRY DETAIL RECORD - RETURN ENTRY 



FIELD 


1 


2 


3 


4 


5 


6 


■ 7 ■ ■ ' ■ 


8 


9 


10 


11 


DATA 

ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


TRANS- 
ACTION 
CODE 


RECEIVING 

DFI 
IDENTIFI- 
CATION 


CHECK 

DIGIT 


DFI 
ACCOUNT 
NUMBER 


AMOUNT 


INDIVIDUAL 
IDENTIFICATION 

NUMBER/ 
IDENTIFICATION 
NUMBER/CHECK 
SERIAL NUMBER 


INDIVIDUAL 

NAME/ 

RECEIVING 

COMPANY NAME 


DISCRETION- 

ARY DATA / 

CARD 

TRANSACTION 
TYPE CODE 


ADDENDA 
RECORD 

INDICATOR 


TRACE 

NUMBER 


Field 

Inclusion 

Requirement 


M 


■ ■ . M 


M 


M 


R 


M 


'.'.'.; .'■. 


R 


R/M 


■'. M 


M 


Contents 


'6' 


1 
Numeric 


2 
TTTTAAAA 


3 
Numeric 


4 
Alphameric 


5 

$$$$$$$$^ 


6 
Alphameric 


6 
Alphameric 


7 
Alphameric 


■1" 


8 
Numeric 


Length 


■'/ 1 


2 


. . 8 


1 


17 


10 


15 ' . ■ ■ 


22 


2 


1 


■'.■'■'■ 15 ■ 


Position 


01-01 


02-03 


04-11 


12-12 


13-29 


30-39 


40-54 


55-76 


77-78 


79-79 


80-94 



Example 


6 


26 


05999999 


'. ■. 7 ■ .■'. 


19650-54326 


0000020000 


3918 


GRACE McGOWAN 


07 


1 


123918710000001 
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Entry Detail Record - Return Entry 

The Entry Detail Record for the example Return Entry is 
shown on the previous page. Note: All fields are the 
same as they were in Entry Detail Record of the original 
entry unless noted otherwise. 

Each field of the Entry Detail Record that has changed 
from the original entry is highlighted below. 

Transaction Code 

The Transaction Code in this example has been changed 
to '26' because this entry is a return entry for a payment 
from a demand deposit account. 

Receiving DFI Identification 



The Receiving DFI Identification field contains 
: 05999999' which is the Routing Number of the institution 
receiving the returned entry (ABC Trust). 



CheckDigit 

The Check Digit is calculated based on the Receiving DFI 
Identification based on the Routing Number of ABC Trust 
(the institution receiving the return). In our example, the 
Check Digit is T. 

Addenda Record Indicator 

The Addenda Record indicator is changed to T to 
indicate that an addenda is carried with this entry. 

Trace Number 

The Trace Number is generated by the institution 
preparing the return. In our example, the Trace Number 
isM23918710000001\ 



ADDENDA RECORD - RETURN ENTRY 



FIELD 


.'■'.'■ .1 '■■ '■ 


■'■■.'■ .2 


3 


4 '. 


5 


6 


7. 


■8 ■ ■ . . 


DATA 

ELEMENT 

NAME 


RECORD TYPE 
CODE 


ADDENDA TYPE 
CODE 


RETURN 

REASON 

CODE 


ORIGINAL ENTRY 
TRACE NUMBER 


DATE OF 

DEATH 


ORIGINAL RECEIVING 
DFI IDENTIFICATION 


ADDENDA INFORMATION 


TRACE NUMBER 


Field 

Inclusion 

Requirement 


M 


M 


M 


'■:'■'■ .-M ■': '. 


O 


R 


o 


M 


Contents 


r 


'99' 


Alphameric 


1 

Numeric 


2 
YYMMDD 


3 
TTTTAAAA 


Alphameric 


Numeric 


Length 


1 


2 


3 


15 


6 


: . ■'■'■'■ 8 ■■'■'. '■"■■■' 


■'■: 44 : 


. -is; ■. 


Position 


01-01 


02-03 


04-06 


07-21 


22-27 


28-35 


36-79 


80-94 



Example 


7 


99 


R01 


059999990000301 




12391871 




123918710000001 



Addenda Record - Return Entry 

An Addenda Record is required for return entries. The 
Addenda Record carries the original entry trace number 
and the Routing Number of the RDFI (original entry). 
The Addenda Record for the example return is shown 
above. 

Key Fields: 

Addenda Type Code 

This field value is ' 99' because it is a return entry. 



Original Entry Trace Number 

The Original Entry Trace Number field contains 
"05999999000030 IV the Trace Number of the Original 
Entry. 

Routing Number 

The Routing Number field carries '.- , 12391871' - the 
Routing Number of the RDFI of the original entry. 

Trace Number 

The Trace Number field is assigned by the financial 
institution originating the return. In this example, the 
trace number is 423918710000001'. 
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COMPANY/BATCH CONTROL RECORD - RETURN ENTRY 


FIELD 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


DATA 

ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


SERVICE 
CLASS 
CODE 


ENTRY/ 

ADDENDA 

COUNT 


ENTRY 
HASH 


TOTAL DEBIT 

ENTRY DOLLAR 

AMOUNT 


TOTAL CREDIT 
ENTRY DOLLAR 

AMOUNT 


COMPANY 
IDENTIFI- 
CATION 


MESSAGE 

AUTHENTICATION 
CODE 


RESERVED 


ORIGINATING 
DFI 
IDENTIFI- 
CATION 


BATCH 

NUMBER 


Field 

Inclusion 

Requirement 


M 


M 


M 


M 


M 


M 


■ ' R 





N/A 


M 


M 


Contents 


' 8 \ 


Numeric 


Numeric 


Numeric 


$$$$$$$$$$(£0 


$$$$$$$$$$00 


Alphameric 


Alphameric 


Blank 


TTTTAAAA 


Numeric 


Length 


1 : 


3 


6 ':'. 


10 


12 


12 


10 


19 


6 


8 


7 


Position 


01-01 


02-04 


05-10 


11-20 


21-32 


33-44 


45-54 


55-73 


74-79 


80-87 


88-94 




Example 


8 


225 


000002 


0005999999 


000000060000 


000000000000 


1047777779 






12391871 


0000001 



Company/Batch Control Record - Return Entry 

The Company/Batch Control Record summarizes the 
information contained in the batch. It contains the counts, 
hash totals, and total dollar controls for the preceding 
detail entries within the batch. 



For an explanation of the Company/Batch Control Record 
and how it is prepared, refer to the NACHA Operating 
Rules and the original entry shown in this section. 




COMPANY/BATCH HEADER RECORD - NOTIFICATION OF CHANGE 



FIELD 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


DATA 

ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


SERVICE 
CLASS 
CODE 


COMPANY 

NAME 


COMPANY 
DISCRE- 
TIONARY 
DATA 


COMPANY 
IDENTIFI- 
CATION 


STANDARD 
ENTRY 
CLASS 
CODE 


COMPANY 

ENTRY 

DESCRIPTION 


COMPANY 
DESCRIPTIVE 

DATE 


EFFECTIVE 
ENTRY 
DATE 


SETTLEMENT 

DATE 

(JULIAN) 


ORIGINATOR 
STATUS 
CODE 


ORIGINATING 

on 

IDENTIFI- 
CATION 


BATCH 

NUMBER 


Field 

Inclusion 

Requirement 


M 


M 


M 


O 


M 


M 


M 


O 


R 


Inserted by 
ACH Operator 


M 


M 


M 


Contents 


'5' 


1 
Numeric 


Alphameric 


Alphameric 


Alphameric 


2 

Alphameric 


3 

Alphameric 


Alphameric 


YYMMDD 


Numeric 


4 
Alphameric 


5 

TTTTAAAA 


6 
Numeric 


Length 


1 


3 


16 


20 


10 


3 


10 


6 


6 


3 


■ 1 


9 


. 7 


Position 


01-01 


02-04 


05-20 


21-40 


41-50 


51-53 


54-63 


64-69 


70-75 


76-78 


79-79 


80-87 


88-94 



Example 


5 


220 


VLS INC 


DIRECT DEPOSIT 


9111111119 


COR 


DIRECT PAY 


062590 


900627 




1 


12391871 


0000002 



Company/Batch Header Record - Notification of Change Standard Entry Class 



Given the information from the Original Entry and the 
additional information listed below, the Company/Batch 
Header Record for the sample Notification of Change is 
shown in the "example" row. Note: All fields are the 
same as they were in the Company/Batch Header of the 
original entry unless otherwise noted. 

The fields that carry information different from the 
Original Entry are explained below. 



The Standard Entry Class is changed to \ COR' for 
Notification of Change Entries. 

Originating DFI Identification 

The Originating DFI Identification is changed from 
;05999999' to * 12391871' to reflect the Routing Number 
of the institution initiating the Notification of Change (the 
RDFI of the Original Entry), 
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Batch Number 



The Batch Number is assigned by the institution preparing 
the Notification of Change Entry. In this example it is 
0000002. 




ENTRY DETAIL RECORD - NOTIFICATION OF CHANGE 


FIELD 


1 


2 


3 


4 


5 


'■■'■'■■ 6 ■.'■ .'■ 


7 


8 


9 


10 


11 


DATA 
ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


TRANS- 
ACTION 
CODE 


RECEIVING DFI 
IDENTIFICATION 


CHECK 

DIGIT 


DFI 
ACCOUNT 

NUMBER 


AMOUNT 


INDIVIDUAL 
IDENTIFICATION 

NUMBER/ 

IDENTIFICATION 

NUMBER 


INDIVIDUAL 

NAME/ 

RECEIVING 

COMPANY NAME 


DISCRE- 
TIONARY 
DATA 


ADDENDA 
RECORD 

INDICATOR 


TRACE 

NUMBER 


Field 

Inclusion 

Requirement 


: . M 


M 


M 


M 


R 


M 


O 


■■':'■' R . '■.'■■.' 


■.'.-.0 : '. 


M 


':'.■ M 


Contents 


'6 1 


1 
Numeric 


2 
TTTTAAAA 


3 
Numeric 


Alphameric 


4 
0000000000 


5 
Alphameric 


5 
Alphameric 


Alphameric 


i' 


'■■'■'.■■■ 6 
Numeric 


Length 


. i : ■ 


2 


8 


.'. 1 


17 


10 


15 


22 


2 


' '. 1 ■' 


15 


Position 


01-01 


02-03 


04-11 


12-12 


13-29 


30-39 


40-54 


55-76 


77-78 


79-79 


80-94 


■ \ 


Example 


6 


21 


05999999 


7 


5568-6547 


0000000000 


121-12-1212 


MARKZARK 


01 


1 


123918710000002 



Entry Detail Record - Notification of Change 

The Entry Detail Record for the example Notification of 
Change is shown in the "example" row. Note: All fields 
are the same as they were in the Entry Detail Record of 
the original entry unless otherwise noted. 

The fields of the Entry Detail Record that carry 
information different from the Original Entry are 
explained below. 

Transaction Code 

The Transaction Code field is changed from 22 to 21 
because this entry is a Notification of Change. 

Receiving DFI Identification 

The Receiving DFI Identification is changed from 
"12391871' to , 05999999' to reflect the Routing Number 
of the institution receiving the Notification of Change 
Entry (the ODFI of the Original Entry). 



'.Check Digit 

The Check Digit is re-calculated based upon the 
Receiving DFI Identification carried in the Notification of 
Change Entry. 

Amount 



The Amount field is Zero for Notification of Change 
Entries. 

Trace Number 

The Trace Number is changed to the Trace Number 
assigned by the institution preparing the Notification of 
Change. In this example, DEF Bank has assigned a trace 
number of 123918710000002. 
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ADDENDA RECORD - NOTIFICATION OF CHANGE 


FIELD 


1 


2 


3 


4 


: 5 : . 


'■'.8 ;.'■'. 


7 


8 


9 


DATA 

ELEMENT 

NAME 


RECORD 
TYPE 

CODE 


ADDENDA 
TYPE 
CODE 


CHANGE CODE 


ORIGINAL ENTRY 
TRACE NUMBER 


RESERVED 


ORIGINAL 
RECEIVING DFI 
IDENTIFICATION 


CORRECTED 
DATA 


RESERVED 


TRACE 
NUMBER 


Field 

Inclusion 

Requirement 


M 


M 


M 


M 


N/A 


R 


M 


N/A 


M 


Contents 


. 7 ' 


'98' 


Alphameric 


1 
Numeric 


Blank 


2 
TTTTAAAA 


Alphameric 


Blank 


Numeric 


Length 


■ ■'■ ■ 1 


2 


3 


/..'■ 15 '■'■'■ ■ 


6 


8 


29 


15 


15 


Position 


01-01 


02-03 


04-06 


07-21 


22-27 


28-35 


36-64 


65-79 


80-94 






Example 


7- 


98 


C01 


059999990000003 




12391871 


68-6547 




123918710000002 



Addenda Record - Notification of Change 

An Addenda Record carries the corrected information 
back to the ODFI of the Original Entry. 

The Addenda Record for the example Notification of 
Change is shown above in the "example row." 

The fields of the Addenda Record that carry information 
different from the Original Entry are explained below. 

Addenda Type Code 

The Addenda Type Code is "98V to indicate that the 
Addenda Record contains automated change information. 

Change Code 

The Change Code in this example is X0T - Incorrect 
Account Number. 



Original Entry Trace Number 

The Original Entry Trace Number carries the Trace 
Number of the original entry. In this example, the 
Original Entry Trace Number is ;059999990000003V 

Routing Number 

The Routing Number field contains the data carried in 
positions 04-1 1 of the original Entry Detail Record (the 
Receiving DFFs Routing Number). 

Corrected Data 

The Corrected Data field carries the change (corrected) 
information corresponding to the change code used. In 
this example, the correct account number ('68-6547') is 
carried in the Corrected Data field. 




COMPANY/BATCH CONTROL RECORD - NOTIFICATION OF CHANGE 



FIELD 


1 


2 


3 


4 


.-.■-. 5'.. ■'.■ 


:..'■• 


.'..-... 7 ;■:.-.■ 


8 


:■■'».■ 


10 


11 


DATA 

ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


SERVICE 
CLASS 
CODE 


ENTRY/ 

ADDENDA 

COUNT 


ENTRY 

HASH 


TOTAL DEBIT 

ENTRY DOLLAR 

AMOUNT 


TOTAL CREDIT 
ENTRY DOLLAR 

AMOUNT 


COMPANY 
IDENTIFICATION 


MESSAGE 
AUTHENTI- 
CATION 
CODE 


RESERVED 


ORIGINATING DFI 
IDENTIFICATION 


BATCH 
NUMBER 


Field 

Inclusion 

Requirement 


M 


M 


M 


M 


.'. M 


'.-.:■' M 


■'■■.■ R 


O 


N/A 


M 


M 


Contents 


'8' 


Numeric 


Numeric 


Numeric 


$$$$$$$$$$<(<( 


$$$$$$$$$$£<( 


Alphameric 


Alphameric 


Blank 


TTTTAAAA 


Numeric 


Length 


1 


3 


6 


10 


12 


1 2 


10 


19 


6 


8 


7 . 


Position 


01-01 


02-04 


05-10 


11-20 


21-32 


33-44 


45-54 


55-73 


74-79 


80-87 


88-94 



Example 


I 8 


220 


000002 


0005999999 


000000000000 


000000000000 


9111111119 






12391871 


0000002 
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Company/Batch Control Record - Notification of Change 

The Company/Batch Control Record summarizes the 
information contained in the batch. It contains the counts, 
hash totals, and total dollar controls for the preceding 
detail entries within the batch. 



For an explanation of the Company/Batch Control Record 
and how it is prepared, refer to the NACH A Operating 
Rules and the original entry shown in this section. 



FILE CONTROL RECORD - RETURN AND NOTIFICATION OF CHANGE ENTRIES 




FIELD 


1 


2 


3 


4 


5 


6 


7 


'■'.'■• 


DATA 

ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


BATCH 

COUNT 


BLOCK 
COUNT 


ENTRY/ 

ADDENDA 

COUNT 


ENTRY HASH 


TOTAL DEBIT 
ENTRY DOLLAR 

AMOUNT IN FILE 


TOTAL CREDIT 
ENTRY DOLLAR 

AMOUNT IN FILE 


RESERVED 


Field 

Inclusion 

Requirement 


M 


M 


M : 


M 


M 


M 


. ■ ■ ■ ■ M ;' 


N/A 


Contents 


■ '9' ■ 


Numeric 


Numeric 


Numeric 


Numeric 


$$$$$$$$$$** 


$$$$$$$$$$£(( 


Blank 


Length 


1 


6 


6 


8 


10 


12 


12 


39 


Position 


01-01 


02-07 


08-13 


14-21 


22-31 


32-43 


44-55 


56-94 



Example 


9 


000002 


000001 


00000004 


0011999998 


000000060000 


000000000000 





File Control Record - Return and Notification of Change 
Entries 



The File Control Record summarizes the information 
carried in the Company/Batch Control Records. It 
contains dollar, entry, and hash total accumulations from 
the Company/Batch Control Records in the file. 



This Record also contains counts of the number of blocks 
and the number of batches within the file. 

For an explanation of the File Control Record and how it 
is prepared, refer to the NACH A Operating Rules and the 
original entry shown in this section. 



E. DISHONORED RETURN ENTRIES 

Given the information in the original entry example, 
return entry example, and additional information that 
follows, this section will illustrate how a dishonored 
return entry is prepared by the ODFI. Note: this section 
will focus on the fields within the Company/Batch, Entry 
Detail, and Addenda Records that contain information 
different from that in the return. The file level and 
company/batch control records are excluded in order, to 
simplify this section. For information on preparing the 
file level and company/batch control records, refer to the 
NA CHA Operating Rules and the sample file records 
prepared for the original entry (section C). 



Additional Information - Dishonored Return Entry 

The return entry, as shown above in section D, is received 
by ABC Trust. The return had to be made available to the 
ODFI by opening of business on June 28 in order to be 
considered timely. For the purposes of this example, 
assume that the return was transmitted on June 27. 
However, due to ACH Operator hardware problems, ABC 
Trust did not receive the return until June 29 (instead of 
June 28). ABC Trust is unable to post the return to UVW 
Club's account because it has declared bankruptcy. Thus, 
ABC Trust suffers a loss and dishonors the return as 
untimely. 
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COMPANY/BATCH HEADER RECORD - DISHONORED RETURNS 



FIELD 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


DATA 

ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


SERVICE 
CLASS 
CODE 


COMPANY 

NAME 


COMPANY 
DISCRETIONARY 

DATA 


COMPANY 
IDENTIB- 
CATION 


STANDARD 
ENTRY 
CLASS 
CODE 


COMPANY 

ENTRY 

DESCRIPTION 


COMPANY 

DESCRIPTIVE 

DATE 


EFFECTIVE 
ENTRY 
DATE 


SETTLEMENT 

DATE 

(JULIAN) 


ORIGINATOR 
STATUS 
CODE 


ORIGINATING 
DFI 
IDENTIFI- 
CATION 


BATCH 
NUMBER 


Field 

Inclusion 

Requirement 


M 


M 


M 


o 


M 


M 


M 


O 


R 


Inserted by 
ACH Operator 


M 


M 


M 


Contents 


'5' 


Numeric 


Alphameric 


Alphameric 


Alphameric 


Alphameric 


Alphameric 


Alphameric 


YYMMDD 


Numeric 


■'.'■■'■' 1 
Alphameric 


2 
TTTTAAAA 


3 

Numeric 


Length 


1 


3 


16 


20 


10 


3 


10 


6 


6 


3 


1 


8 


7 


Position 


01-01 


02-04 


05-20 


21-40 


41-50 


51-53 


54-63 


64-69 


70-75 


76-78 


79-79 


80-87 


88-94 




Example 


5 


225 


UVW 
CLUB 


DUES 


1047777779 


PPD 


MONTH-DUES 


062590 


900626 




1 


05999999 


0000001 




Company/Batch Header - Dishonored Return Entry 



Originating DFI Identification 



The Company/Batch Header Record layout for the This field contains * 05999999' - ABC Trust's Routing 
example Dishonored Return Entry is shown above. Number. 



The following fields contain information different from Batch Number 

the return entry: 

This field contains "000000 1 '- the batch number assigned 
by ABC Trust to the Dishonored Return. 



ENTRY DETAIL RECORD - DISHONORED RETURN 



FIELD 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


DATA 
ELEMENT 

NAME 


RECORD 
TYPE 

CODE 


TRANS- 
ACTION 
CODE 


RECEIVING DFI 
IDENTIFICATION 


CHECK 

DIGIT 


DFI 

ACCOUNT 
NUMBER 


AMOUNT 


INDIVIDUAL 
IDENTIFICATION 

NUMBER/ . 
IDENTIFICATION 
NUMBER/CHECK 
SERIAL NUMBER 


INDIVIDUAL 

NAME/ 

RECEIVING 

COMPANY 

NAME 


DISCRE- 
TIONARY 
DATA 


ADDENDA 
RECORD 
INDICATOR 


TRACE 
NUMBER 


Field 

Inclusion 

Requirement 


M 


M 


M 


M 


R 


M 


O 


R 


. . R ■■ 


M 


M 


Contents 


'6' 


Numeric 


1 
TTTTAAAA 


2 
Numeric 


Alphameric 


$$$$$$$$*<! 


Alphameric 


Alphameric 


Alphameric 


T 


3 
Numeric 


Length 


1 


2 


8 


1 


17 


10 


■ ■ '. : ■' is '■.' 


22 


2 


1 


. . 15 . 


Position 


01-01 


02-03 


04-11 


12-12 


13-29 


30-39 


40-54 


55-76 


77-78 


79-79 


80-94 



Example 


6 


26 


12391871 





19650-54326 


0000020000 


000000000003918 


GRACE 
McGOWAN 


07 


1 


059999990000001 



Entry Detail Record - Dishonored Return Entry 

The Entry Detail Record for the sample Dishonored 
Return Entry is shown above. 



The fields that carry information different from the return 
entry are listed on the following page. 
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Receiving DFI Identification 

This field contains the Routing Number of the institution 
receiving the Dishonored Return. In this example, the 
Receiving DFI Identification is 12391871' (DEF Bank's 
Routing Number). 

CheckDigit 



In our example, the check digit is "OY 

Trace Number 

This field carries the trace number assigned by ABC Trust 
(the institution preparing the dishonored return). ABC 
Trust assigned a trace number of "059999990000001Y 



This field carries the check digit which is calculated based 
on the Receiving DFI Identification./ 



ADDENDA RECORD - DISHONORED RETURN ENTRIES 


FIELD 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


DATA 

ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


ADDENDA 
TYPE 
CODE 


DISHONORED 

RETURN 
REASON CODE 


ORIGINAL 

ENTRY TRACE 

NUMBER 


RESERVED 


ORIGINAL 
RECEIVING DFI 
IDENTIFICATION 


RESERVED 


RETURN 
TRACE 
NUMBER 


RETURN 
SETTLE- 
MENT 
DATE 


RETURN 

REASON 

CODE 


RESERVED 


TRACE 
NUMBER 


Field 

Inclusion 

Requirement 


M 


M 


M 


M 


N/A 


R 


N/A 


■ M ■ ■ ■ 


■ . M - 


M 


N/A 


M 


Contents 


T 


'99' 


Alphameric 


1 
Numeric 


Blank 


2 
TTTTAAAA 


Blank 


Numeric 


Numeric 


Alphameric 


Blank 


3 
Numeric 


Length 


1 


2 


3 


15 


6 


8 


3 


15 


3 


2 


21 


15 


Position 


01-01 


02-03 


04-06 


07-21 


22-27 


28-35 


36-38 


39-53 


54-56 


57-58 


59-79 


80-94 




Example 


7 


99 


R68 


059999990000301 


!■'■'■'' 


12391871 




123918710000001 


179 


01 




05999999 
0000001 



Addenda Record - Dishonored Return Entry 

The Addenda Record for the sample dishonored return is 
shown above. 

The fields which require special attention are outlined 
below. 

Original Entry Trace Number 

The Original Entry Trace Number field contains 
> 059999990000301 t - the Trace Number of the Original 
Entry. This number is obtained from positions 7 - 2 1 of 
the Addenda Record of me Return entry. 

Routing Number 

The Routing Number field carries ; 1 239 1 87 V - the 
Routing Number of the RDFI of the original entry. This 
number is copied from positions 28 - 35 of the Addenda 
Record of the Return entry . 



Trace Number 

The Trace Number is changed to reflect the trace number 
carried in the Entry Detail Record of the Dishonored 
Return. In our example, the trace number is 
: 059999990000001'. 

Dishonored Return Reason Code 

In our example, the reason for dishonoring the return is 
that the return was untimely ('R68'). 

The following fields are also important in the dishonor 
process: 

Date of Original Return 

This field is obtained from the Effective Entry Date of the 
original return. In our example, the value is "900628'. 
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Return Trace Number 

This field is obtained from the Trace Number field of the 
return entry. In this example, the value is 
* 1239 187 10000001'. 



Return Reason Code 

The information in this field is obtained from the return 
entry. In our example, it is R01. 



Return Settlement Date 

This field is copied from the Settlement Date field of the 
return entry. The Return Settlement Date in our example 

is.- iW: ■:.::■' ■.'■.■■ 



F. REFUSED NOTIFICATIONS OF CHANGE 

Assume the sample Notification of Change is sent as 
shown above in section D, with one exception - DEF 
Bank (the RDFI) sends the wrong Trace Number. The 
Trace Number should have been 059999990000003 but 
was sent as 059999990000303. ABC Trust (the ODFI) 
receives the Notification of Change and cannot identify 
the original entry because of the error. The ODFI 
prepares a Refused Notification of Change. 



In order to simplify this section, only the Addenda Record 
of the Refused Notification of Change is shown. The File, 
Company/Batch, and Entry records are prepared in a 
similar manner to that shown in the sample notification of 
change (section D). The Addenda Record of the Refused 
Notification of Change, as prepared by ABC Trust, is 
shown in the "example" row below. 




In this example, the Addenda Record notifies the 
Originator of the Notification of Change (RDFI of the 
Original Entry) that the Notification of Change contained 
incorrect information. 



ADDENDA RECORD - REFUSED NOTIFICATION OF CHANGE 


FIELD 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


DATA 

ELEMENT 
NAME 


RECORD 
TYPE 
CODE 


ADDENDA 
TYPE 
CODE 










CORRECTED 
DATA 


CHANGE 
CODE 


COR TRACE" 

SEQUENCE 

NUMBER 


RESERVED 


TRACE 

NUMBER 


REFUSED 
COR CODE 


Original entry 
trace number 


RESERVED 


ORIGINAL 
RECEIVING DFI 
IDENTIFICATION 


Field 

Inclusion 

Requirement 


M 


M 


M 


M 


N/A 


R 


M 


M 


M 


N/A 


: m 


Contents 


T 


'98' 


Alphameric 


■ 1 
Numeric 


Blank 


2 
TTTTAAAA 


Alphameric 


3 
Alphameric 


Numeric 


Blank 


Numeric 


Length 


.1 


2 


3 


15 


6 


8 


29 


3 


■ 7 : 


5 


15 


Position 


01-01 


02-03 


04-06 


07-21 


22-27 


28-35 


36-64 


65-67 


68-74 


75-79 


80-94 




Example 


7 


98 


C01 


059999990000003 




05999999 


68-6547 


C62 


0000002 




059999990000001 



Several key fields of the Addenda Record are explained 
below. 

Change Code 

The Change Code field carries the Change Code found in 
the Original Notification of Change (field 3). In this 
example, the Change Code is * C01\ 



Original Entry Trace Number 

The Original Entry Trace Number field is obtained from 
field 4 of the Notification of Change. Thus, the Original 
Entry Trace Number is ^059999990000003'. 
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Routing Number 

The Routing Number field carries the Routing Number of 
the ODFI of the original entry (the institution originating 
the Refused Notification of Change). In our example, this 
field carries ^05999999'- ABC Trust's Routing Number. 

Corrected Data 

The Corrected Data field carries the same information 
found in the Corrected Data field of the Notification of 
Change. In our example, the Corrected Data is ' 68-6547*. 



Refused COR Code 

The Refused COR Code field contains a code specifying 
the reason the Notification of Change is being refused. In 
the example above, the code is "C62\ 

COR Trace Sequence Number 

The COR Trace Sequence Number carries the last seven 
digits of the Trace Number contained in the original 
notification of change. In our example, the COR Trace 
Sequence Number is x 0000002'. 




G. CONTESTED DISHONORED RETURN 

ENTRIES ■■■■■■: 

Given the information in the original, return, and 
dishonored return entry examples and in the additional 
information that follows, this section will illustrate how a 
contested dishonored return entry is prepared by the 
RDFI. Note: this section will focus on the fields within 
the Company/Batch, Entry Detail, and Addenda Records 
that contain information different from that found in the 
return. The file level and company/batch control records 
are excluded in order to simplify this section. For 
information on preparing the file level and company/batch 
control records, refer to the NACHA Operating Rules and 
the example file records prepared for the original entry 
(section C). 



Additional Information - Contested Dishonored Return 
Entry 

The dishonored return entry, as shown above in section E, 
is received by DEF Bank. DEF Bank disputes the fact 
that the original return was untimely. The return had to be 
made available to the ODFI by opening of business on 
June 28 in order to be considered as timely. 

DEF Bank transmitted the return on June 27, but, due 
hardware problems at Receiving ACH Operator, the 
return was not settled until June 29. Thus, ABC Trust 
(the Originator of the dishonored return) considered the 
return to be untimely. 



COMPANY/BATCH HEADER RECORD -CONTESTED DISHONORED RETURNS 



FIELD 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 










DATA 

ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


SERVICE 
CLASS 
CODE 


COMPANY 

NAME 


COMPANY 

DISCRETIONARY 

DATA 


COMPANY 

IDENTIFICATION 


STANDARD 
ENTRY 
CLASS 
CODE 


COMPANY 

ENTRY 

DESCRIPTION 


COMPANY 

DESCRIPTIVE 
DATE 


EFFECTIVE 
ENTRY 
DATE 


SETTLEMENT 

DATE 

(JULIAN) 


ORIGIN- 
ATOR 

STATUS 
CODE 


ORIGINATING 
DFI 
IDENTIFI- 
CATION 


BATCH 

NUMBER 


Field 

Inclusion 

Requirement 


M 


M 


M 


O 


M 


M 


M 


O 


R 


Inserted by 
ACH Operator 


M 


M 


M 


Contents 


5' 


Numeric 


Alphameric 


Alphameric 


Alphameric 


Alphameric 


Alphameric 


Alphameric 


YYMMDD 


Numeric 


....... A 

Alphameric 


. 2 
TTTTAAAA 


3 
Numeric 


Length 


1 


3 


16 


20 


10 


3 


10 


6 


6 


3 


1 


8 


7 


Position 


01-01 


02-04 


05-20 


21-40 


41-50 


51-53 


54-63 


64-69 


70-75 


76-78 


79-79 


80-87 


88-94 



Example 


5 


225 


UVW CLUB 


DUES 


1047777779 


PPD 


MONTH-DUES 


062590 


900626 




1 


12391871 


0000001 



Company/Batch Header - Contested Dishonored Return 
Entry 

The Company/Batch Header Record layout for the 
example Contested Dishonored Return Entry is shown 
above. 

The fields that contain information different from the 
dishonored return entry are listed on the following page. 



Originating DFI Identification 

This field contains * 1 239 1 87 1', DEF Bank's Routing 
Number. 

Batch Number 

This field contains "0000001' - the batch number assigned 
by DEF Bank to the contested dishonored return. 



OG152 



2005 OPERATING GUIDELINES 



SECTION IV - SPECIAL TOPICS 
CHAPTER VII - MAPPING 



ENTRY DETAIL RECORD - CONTESTED DISHONORED RETURN ENTRIES 



FIELD 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


DATA 

ELEMENT 

NAME 


RECORD 
TYPE 
CODE 


TRANSACTION 

CODE 


RECEIVING 

DFI 
IDENTIFI- 
CATION 


CHECK 
DIGIT 


DFl 
ACCOUNT 
NUMBER 


AMOUNT 


INDIVIDUAL 
IDENTIFICATION 

NUMBER/ 
IDENTIFICATION 
NUMBER/CHECK 
SERIAL NUMBER 


INDIVIDUAL 

NAME/ 
RECEIVING 

COMPANY 
NAME 


DISCRE- 
TIONARY 

DATA 


ADDENDA 
RECORD 
INDICATOR 


TRACE 

NUMBER 


Field 

Inclusion 

Requirement 


M 


M 


M 


M 


R 


M 





R 


R 


'■'■'.' M 


'■ : m ■' : ■'■'■ 


Contents 


'6* 


Numeric 


1 
TTTTAAAA 


2 
Numeric 


Alphameric 


$$$$$$$$**. 


Alphameric 


Alphameric 


Alphameric 


'1' ■ ■ ■ 


3 
Numeric 


Length 


.' . 1 . ■ . 


. . 2 


8 


;.■'. !■ .■ . 


17 


10 


15 


22 


2 


1 


15 


Position 


01-01 


02-03 


04-11 


12-12 


13-29 


30-39 


40-54 


55-76 


77-78 


79-79 


80-94 



Example 


6 


26 


05999999 


7 


19650-54326 


0000020000 


000000000003918 


GRACE 
McGOWAN 


07 


1 


123918710000001 



Entry Detail Record - Contested Dishonored Return Entry Check Digit 



The Entry Detail Record for the example Contested 
Dishonored Return Entry is shown above. 

The fields that carry information different from that found 
in the dishonored return entry are listed below. 

Receiving DFI Identification 

This field contains the Routing Number of the institution 
receiving the contested dishonored return. In this 
example, the Receiving DFI Identification is '05999999' 
(DEF Bank's Routing Number). 



This field carries the check digit, which is calculated 
based on the Receiving DFI Identification. In our 
example, the check digit is T. 

Trace Number 

This field carries the trace number assigned by DEF Bank 
(the institution preparing the dishonored return). DEF 
Bank assigned a trace number of ' 123918710000001'. 



ADDENDA RECORD - CONTESTED DISHONORED RETURNS ENTRIES 



FIELD 


1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


DATA 

BLEMBNT 

NAME 


RECORD 
TYPE 
CODE 


ADDENDA 
TYPE 
CODE 


CONTESTED 

DISHONOR 

RETURN 

REASON 

CODE 


ORIGINAL 
ENTRY 
TRACE 

NUMBER 


DATE 
ORIGINAL 

ENTRY 
RETURNED 


ORIGINAL 
RECEIVING DFI 
IDENTIFICATION 


ORK3WAL 

SETTLEMENT 

DATE 

(JULIAN) 


RETURN 
TRACE 
NUMBER 


RETURN 

SETTLEMENT 

DATE 


RETURN 
REASON 
CODE 


DISHONORED 
RETURN 
TRACE 
NUMBER 


DISHONORED 

RETURN 

SETTLEMENT 

DATE 


DISHONORED 
RETURN 
REASON 
CODE 


RESERWO 


TRACE 
NUMBER 


Field 

Inclusion 

Requirement 


M 


M 


M 


M 


O 


R 


M 


M 


M 


M 


M 


M 


M 


N/A 


M 


Contents 


T 


'99' 


Alphameric 


1 

Numeric 


2 
YYMMDD 


3 
TTTTAAAA 


2 

Numeric 


Numeric 


Numeric 


Alphameric 


Numeric 


Numeric 


Alphameric 


Blank 


''.'■"' 4 
Numeric 


Length 


1 


2 


3 


15 


6 


8 


3 


15 


3 


2 


15 


3 


2 


1 


15 


Position 


01-01 


02-03 


04-06 


07-21 


22-27 


28-35 


36-38 


39-53 


54-56 


57-58 


59-73 


74-76 


77-78 


79-79 


80-94 




Example 


7 


99 


R73 


05999999 
0000301 


900628 


12391871 


176 


12391871 
0000001 


179 


01 


05999999 
0000001 


183 


68 




12391871 
0000001 
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Addenda Record - Contested Dishonored Return Entry 

The Addenda Record for the example contested 
dishonored return is shown above. 

The fields which require special attention are outlined 
below. 

Contested Dishonored Return Reason Code 

Original Entry Trace Number 

The Original Entry Trace Number field contains 
;059999990000301'- the Trace Number of the Original 
Entry. This number is obtained from positions 7-21 of 
the Addenda Record of the return entry. 

Routing Number 



The Routing Number field carries 1239187T - the 
Routing Number of the RDFI of the original entry. This 
number is copied from positions 28 - 35 of the Addenda 
Record of the return entry. 

Trace Number 

The Trace Number is changed to reflect the trace number 
carried in the Entry Detail Record of the Dishonored 
Return. In our example, the trace number is 
:059999990000001\ 

The following fields also are key fields and are obtained 
from either the original entry, return entry, or dishonored 
return entry. 

Original Settlement Date 

Return Trace Number 

Return Settlement Date 

Return Reason Code 

Dishonored Return Trace Number 

Dishonored Return Settlement Date 

Dishonored Return Reason Code 



SEGTIONIV : 
SPECIAL TOPICS 

CHAPTER VIII : 
AUTOMATED ENROLLMENT 
ENTRIES 

A. INTRODUCTION 

The Automated Enrollment process provides Depository 
Financial Institutions (DFIs) with a mechanism to transmit 
enrollments for future ACH credits and debits to Federal 
Government Agencies, via the ACH Network, on behalf 
of both consumer and corporate account holders/The 
ENR process provides a platform for Federal Government 
Agencies to utilize the ACH Network to accommodate 
enrollments for ACH debit activity (in addition to the 
current credit enrollment capability) and to accept 
enrollment information for corporate applications. 

This chapter addresses issues relating to the origination of 
Automated Enrollment (ENR) entries. The Automated 
Enrollment process allows the ACH Network to be 
utilized by a Depository Financial Institution (DFIs) to 
transmit ACH enrollment information for both credit and 
debit applications to Federal Government Agencies on 
behalf of its account holder (i.e., a consumer or company). 
The initiation and acceptance of Automated Enrollment 
(ENR) entries is completely voluntary. A depository 
financial institution may, but is not required to, initiate 
ENR entries to transmit account holder enrollment 
information. Similarly, Federal Government Agencies 
may, but are not required to, accept and process ENR 
entries. 

An Automated Enrollment entry is a non-dollar entry that 
maybe transmitted through the ACH by any Depository 
Financial Institution to any Federal Government Agency 
participating in the ENR program. This chapter addresses 
the responsibilities of the DFI that originates Automated 
Enrollment entries and the Federal Government Agency 
that receives those entries. 

B, RESPONSIBILITIES OF DFIs 

1. ORIGINATION OF AUTOMATED 

ENROLLMENT ENTRIES : 



The initiation of ENR entries by a DFI is completely 
voluntary. A DFI may, at its option, elect to transmit 
consumer or corporate ACH enrollment information on 
behalf of its account holder to any Federal Government 
Agency participating in the ENR program. In transmitting 
ENR entries, DFIs will be subject to the liabilities and 
responsibilities relating to the initiation of enrollment 
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entries as governed by the provisions of Title 31 of the 
Code of Federal Regulation, Part 210. (For detailed 
information on the RDFFs responsibilities and liabilities 
for these entries, RDFIs should consult the most recent 
release of 31 CJF.R. Part 2 10.) 

2. TIMING OF OMGINATION 

Automated Enrollment entries may be originated at any 
time. 

3; FORMAT REQUIREMENTS 

The preferred method of providing enrollment 
information to a Federal Government Agency on behalf of 
a customer (either consumer or corporate) is the 
Automated Enrollment format. When initiating an 
Automated Enrollment entry, the following guidelines 
apply: 

• The word "AUTOENROLL" must appear in the 
Company Entry Description field of the 
Company/Batch Header Record. 

• The information contained in the Entry Detail Record 
pertains to the Federal Government Agency that is 
receiving the Automated Enrollment entry; 

• The Transaction Code in the Entry Detail Record 
must contain either a"23" or"33" (Prenotification of 
Demand Credit / Savings Credit Authorization). 

•..'.■ The Receiving DFI Identification field of the Entry 
Detail Record must include the routing number of the 
Federal Government Agency that is receiving the 
Automated Enrollment entry: 

Federal Agency/Benefits Routing Number/Check Digit 

Social Security Administration 6550-6004 2 

(Social Security, Supplemental 
Security Income) 

Department of Veterans Affairs 1117-3699 1 

(Veterans Benefits) 

Railroad Retirement Board 11 17-3699 1 

(Railroad Retirement Benefits) 

Office of Personnel Management 1117-3699 1 

(Federal Civil Service) 

• The DFI Account Number included in the Entry 
Detail Record must include the following information 
provided by the participating Federal Government 
Agency: 



Federal Agencv/Benefits Account Number 

Social Security Administration (Blanks) 

(Social Security, Supplemental 
Security Income) 

Department of Veterans Affairs (Blanks) 

(Veterans Benefits) 

Railroad Retirement Board (Blanks) 

(Railroad Retirement Benefits) 

Office of Personnel Management (Blanks) 
(Federal Civil Service) 

° The Amount field of the Entry Detail Record is 
always zero. 

> The Identification Number field of the Entry Detail 
Record should include the following information 
provided by the participating Federal Government 
Agency: 

Federal Agencv/Benefits Identification Number 

Social Security Administration (Blanks) 

(Social Security, Supplemental 
Security Income) 

Department of Veterans Affairs (Blanks) 

(Veterans Benefits) 

Railroad Retirement Board (Blanks) 

(Railroad Retirement Benefits) 

Office of Personnel Management (Blanks) 

(Federal Civil Service) 

> At least one addenda record must accompany the 
Entry Detail Record. The addenda record contains 
the enrollment data being transmitted to the Federal 
Government Agency on behalf of the consumer(s) 
and/or company(ies). Up to 9,999 addenda records 
may accompany a single Entry Detail Record. 

:•'. The Receiving Company Name/ID Number included 
in the Entry Detail Record should include the 
following information provided by the participating 
Federal Government Agency: 




Federal Agency/ 
Benefits 



Receiving Company 
Name/ID Number 



Social Security Administration SOCIALbSECURITYb 
(Social Security) 

Social Security Administration SUPPbSECURITYbbb 
(Supplemental Security Income) 
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Department of Veterans Affairs 

(Veterans Compensation 

& Pension) VAbCOMP/PENSION 

(Veterans Education MGIB) VAbEDUCATNbMGIB 

(Veterans Education/Selected 

Reserve) VAbEDUCbMGIB/SR 



(Veterans Life Insurance) 



VAbLIFEblNSUR 



(Veterans Vocational Rehabilitation 

& Employment Benefits) VAbVOCbREHABbEMP 

Railroad Retirement Board RAILROADbRETbBDb 

(Railroad Retirement/ 
Annuity Benefits) 




RAILROADbUISIbbb 



CIVILbSERVbCSAbb 



CIVILbSERVbCSFbb 



Railroad Retirement Board 

(Railroad Retirement 

Unemployment/Sickness 

Benefits) 

Office of Personnel 
Management 

(Federal Civil Service 
Retirement/Annuity) 

Office of Personnel 
Management 

(Federal Civil Service 
Survivor/Annuity) 



Addenda Type Code "05" must be used. 

The information (see "NOTE") included in the 
Payment Related Information field of the addenda 

record pertains to one consumer or company on 
whose behalf the enrollment is being forwarded to the 
participating Federal Government Agency. A 
separate addenda record should be used for each 
enrollment being prepared. The information 
appearing in this field will contain the following 
NACH A endorsed banking convention: 



Transaction Code 



This is a 2-position field 
containing the Transaction Code 
of the account holder's account. 
The field should contain either a 
"22" (Automated Deposit for 
Demand Credit Account Records), 
"27" (Automated Payment for 
Demand Debit Account Records), 
"32" (Automated Deposit for 
Savings Account Credit Records), 
or "37" (Automated Payment for 
Savings Account Debit Records). 

Note : For direct deposit credit 
enrollments for Federal 



Government benefit payments, 

the Transaction Code contained 
within the Payment Related 
Information Field of the addenda 
record must contain either a "22" 
(Automated Deposit for Demand 
Credit Account Records) or a "32" 
(Automated Deposit for Savings 
Account Credit Records). Use of 
any other transaction code within 
this field will cause the enrollment 
entry to be returned by the Federal 
Government Agency. 

This 8-position field contains the 
routing number used to identify 
the DFI at which the account 
holder maintains its account. 

This 1 -position field contains the 
Check Digit pertaining to the 
routing number for the DFI at 
which the account holder 
maintains its account. 



DFI Account Number This field (1 to 17 positions) 
contains the account holder's 
account number at the DFI. 



Receiving DFI 

Identification 

Number 



Check Digit 



Individual 

Identification 

Number/ 

Identification 

Number 



For automated enrollments initi- 
ated on behalf of consumers, this 
9-position field contains the con- 
sumer's own Social Security Num- 
ber (i.e., as opposed to the SSN 
that may appear on the monthly 
benefit check from the Federal 
Government Agency) . For 
automated enrollments initiated on 
behalf of companies, this field will 
contain the company's Taxpayer 
Identification Number. 



Individual Name This field ( 1 to 1 5 positions) con- 
(SurnameJ/Company tains the consumer's surname or 
Name the first fifteen characters of the 

company name. 



Individual Name 
(First Name)/ 
Company Name 



This field (1 to 7 positions) con- 
tains the consumer's first name or 
the next seven characters of the 
company name. 



Representative Payee For direct deposit credit enroll- 
Indicator/Enrollee ments for Federal Government 
Classification Code benefit payments, this field will 
contain either a "0" (zero) 
meaning "no" or a "1" (one) 
meaning "yes" to denote whether 
the authorization is being initiated 
by someone other than the named 
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Terminator 



' NOTE: 



beneficiary. A representative 
payee (either individual or 
institution) may authorize a direct 
deposit enrollment on behalf of the 
entitled beneficiary who is 
mentally or physically incapable of 
handling their own funds. 

For all other enrollments, this 
field will contain "A" to indicate 
that the enrollee is a consumer, or 
a "B" to indicate that the enrollee 
is a company. ■■.'.■■ 

Include a "\" (backslash) as the 
convention for the end of the 
segment indicator. 

All data fields included in the Payment 
Related Information field of the addenda 
record are separated by an asterisk (*) 
delimiter. 



EXAMPLE 

22* 12200004*3* 12398765432 l*777777777*DOE* 
JOHN*0\ 

27*12200004*3*123987654321*777777777*DOE 
*JOHN*A\ 



27*12200004*3*987654321 123*876543210*ABC 
ELECTRONICIN*DUSTRIE*B\ 



4. RESPONSES TO AUTOMATED ENROLLMENT 

. ENTRIES . 

There are three ways that a DPI can receive a response to 
an Automated Enrollment entry that it originates: 

• The Automated Enrollment entry may be returned by 
the ACH Operator as unprocessable; 

• The Automated Enrollment entry may be returned by 
the Federal Government Agency as unprocessable; 

•' The Automated Enrollment entry may result in the 
transmission of future credit and/or debit entries 
between the account holder and the Federal 
Government Agency. 

If an Automated Enrollment entry is returned by the ACH 
Operator, the DFI originating the ENR entry should be 
aware that the participating Federal Government Agency 
has never received the enrollment. After correction, 
another Automated Enrollment entry should be initiated. 
(See the chapter on Returns, Dishonored Returns, and 
Contested Dishonored Returns in Section III of these 



Guidelines for a description of ACH Operator return 
reason codes.) 

If an Automated Enrollment entry is returned by a Federal 
Government Agency that is not a participant in this 
program, the DFI originating the ENR entry should 
inform the account holder to contact the Federal 
Government Agency directly (i.e., outside the ACH 
Network) regarding the enrollment. (The DFI may 
contact the Federal Government Agency directly, outside 
the ACH Network, on the account holder's behalf if it so 
chooses.) 

If the Automated Enrollment entry is returned by a 
participating Federal Government Agency because the 
entry is unprocessable, the DFIoriginating the ENR entry 
should be aware that the agency has not acted upon the 
enrollment. After correction, another Automated 
Enrollment entry should be initiated. 

5. USE OF A THIRD-PARTY SERVICE PROVIDER 
TO ORIGINATE AUTOMATED ENROLLMENT 

. ENTRIES 

If the DFI is unable to automate this process, it may wish 
to use the services of a Third-Party Service Provider for 
the conversion of consumer enrollment information to the 
Automated Enrollment (ENR) format prior to delivery to 
the ACH Operator. When using a Third-Party Service 
Provider for this purpose, the RDFI should be aware that 
it retains the responsibilities and liabilities relating to the 
transmission of these entries. 

6. RETURNED AUTOMATED ENROLLMENT 
ENTRIES 

A DFI should be aware that an Automated Enrollment 
entry that it has originated may not be processed for 
certain reasons. An Automated Enrollment entry can be: 

Returned by the ACH Operator — Once an Automated 
Enrollment entry has been transmitted to the ACH 
Operator, it could reject for specific reasons. In such a 
case, the ACH Operator will transmit a return to the DFI 
with a return reason code indicating why the entry could 
not be processed (see Appendix Three, Specifications for 
Data Acceptance, in the NACHA Operating Rules for a 
complete description of ACH Operator return reason 
codes). 

Returned by the Federal Government Agency receiving 
the Automated Enrollment entry ~ In this case, the 
Automated Enrollment entry has been processed through 
the ACH system; however, the Federal Government 
Agency receiving the ENR entry was not able to handle it 
for a specific reason. The Federal Government Agency 
may use the ACH return process to indicate why the ENR 
entry could not be processed. 
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In the event that the Federal Government Agency is 
unable to process an enrollment, information relating to 
the consumer or corporate enrollee will be returned to the 
DFI, along with an appropriate return reason code to 
indicate the reason for the return. ENR return entries are 
formatted using the Entry Detail Record Format for 
Returns. For information on the formatting requirements 
for return entries, refer to Appendix Five (Return Entries) 
within the NACHA Operating Rules. 



Reasons for Return of Automated Enrollment Entries by 
Participating Federal Government Agencies 

The following return reason codes may be used by 
participating Federal Government Agencies to return 
Automated Enrollment entries. 

R40 Return of ENR Entry by Federal Government 
Agency (ENR only). The Federal Government Agency 
that received the Automated Enrollment entry has chosen 
not to accept ENR entries. DFIs, Receivers should 
contact the Agency outside the ACH system regarding the 
enrollment information. 

The following return reason codes relate to the contents 
of the addenda records associated with the ENR entry: 



R41 Invalid Transaction Code. The 2-position 
Transaction Code included in Field 3 of the Addenda 
Record is something other than "22" (Automated Deposit 
for Demand Account Credit Records), "27" (Automated 
Payment for Demand Debit Account), "32" (Automated 
Deposit for Savings Account Credit Records) , or "3 7 " 
(Automated Payment for Savings Account Debit 
Records). The transaction code contained within the 
Payment Related Information field of the addenda record 
is used to indicate the type of ACH entry that will be 
originated either by the DFI' s account holder or the 
Federal Agency. 

Note : For direct deposit credit enrollments for Federal 
Government benefit payments, the Transaction Code 
contained within the Payment Related Information Field 
of the addenda record must contain either a "22" 
(Automated Deposit for Demand Credit Account Records) 
or a "32" (Automated Deposit for Savings Account Credit 
Records) . Use of any other transaction code within this 
field will cause the enrollment entry to be returned by the 
Federal Government Agency. 

R42 Routing Number/Check Digit Error. The routing 
number of the Receiver's financial institution contained 
within the Payment Related Information field of the 
addenda record is incorrect. The routing number and 
check digit for the Receiver's financial institution are 
necessary for the Federal Government Agency to transmit 
future ACH payments to the Receiver' s account. An 
invalid routing number and/or check digit will cause the 



enrollment entry to be returned by the Federal 
Government Agency. 

R43 Invalid DFI Account Number. The enrollee's 
account number at the DFI (contained within the Payment 
Related Information Field of the addenda record) is either 
missing, exceeds 17 positions, or contains invalid 
characters. The enrollee's account number is necessary 
for the Federal Government Agency to transmit future 
ACH transactions to the enrollee. An invalid account 
number will cause the enrollment entry to be returned by 
the Federal Government Agency. 

R44 Invalid Individual ID Number/Identification 
Number. The enrollee's identification number contained 
within the Payment Related Information field of the 
addenda record is either invalid (e.g., contains more or 
fewer than 9 digits or is otherwise an invalid number), or 
it does not match a corresponding identification number 
in the Federal Agency's records. The enrollee's valid 
identification number is necessary for the Federal 
Government Agency to process the enrollment 
information. An invalid identification number or one not 
matching the Federal Agency's records will cause the 
enrollment entry to be returned by the Agency. 

R45 Invalid Individual Name/Company Name. The 

name of the enrollee provided in the Payment Related 
Information field of the addenda record either does not 
match a corresponding name in the Federal Agency's 
records, or it fails to include at least one alphameric 
character. The enrollee's name is necessary for the 
Federal Agency to process the enrollment information. 
An enrollee's name not matching the Federal Government 
Agency's records or not containing alphameric characters 
will cause the enrollment entry to be returned by the 
Agency. 

R46 Invalid Representative Payee Indicator. The 

Representative Payee Indicator Code included in the 
Payment Related Information field of the addenda record 
has been omitted or is not consistent with the Federal 
Agency's records. The Representative Payee Indicator 
code must be either a "zero" to denote that the payment 
will be sent to the Receiver, or a "one" to denote that the 
payment will be sent to a representative payee on behalf 
of an entitled beneficiary. (Example: The Representative 
Payee Indicator Code is "zero" and Social Security's 
records indicate that payments should be sent to a 
representative payee on behalf of an entitled beneficiary.) 

Note : For direct deposit credit enrollments for Federal 
Government benefit payments, the Representative Payee 
Indicator field must contain a "0" (zero) or a "1 ."■ (one). 
Any other code in this field will cause the enrollment 
entry to be returned by the Federal Government Agency. 

R47 Duplicate Enrollment. The Federal Agency has 
received duplicate Automated Enrollment entries from the 
same DFI. 
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C, RESPONSIBILITIES OF FEDERAL 

GOVERNMENT AGENCIES RECEIVING 
AUTOMATED ENROLLMENT ENTRIES 

Use of the Automated Enrollment process and acceptance 
of ENR entries by a Federal Government Agency is 
completely voluntary. Federal Government Agencies 
may, but are not required to, accept and process ACH 
credit enrollments using the ENR process. Federal 
Government Agencies that receive Automated Enrollment 
entries are required to act upon those entries by taking one 
of two possible actions: 



Return the Entry 

Federal Government Agencies that either do not 
participate in the Automated Enrollment program or 
cannot process an ENR entry because of a problem 
with the information contained within the entry 
should return the entry using the appropriate return 
reason code. 

Apply the Enrollment Information to the Agency *s 
Records 

Participating Federal Government Agencies that 
receive an Automated Enrollment entry containing 
correct and proper information should apply the entry 
to the corresponding enrollee's (i.e., the consumer's 
or corporation's) records as quickly as possible. 

Automated Enrollment entries for consumer benefit 
payments that are transmitted late in the month may 
not be received by the Agency in time to effect the 
next scheduled payment by direct deposit. In such 
instances, direct deposit will begin with the 
subsequent payment. For example, an Automated 
Enrollment entry transmitted on November 25 may 
not be processed by the Federal Agency in time for 
the December 3 benefit payment to be made to the 
Receiver via direct deposit. In this case, direct 
deposit would begin with the next benefit payment to 
be made on January 3. 



SEGTIONIV 
SPECIAL TOPICS 

CHAPTER IX 

DESTROYED CHECK ENTRIES 

A/ INTRODUCTION 

This chapter addresses issues relating to the origination 
and receipt of Destroyed Check Entries (XCK). XCK 



allows the ACH to be utilized by a collecting financial 
institution for the collection of certain checks when those 
checks have been destroyed or lost. Destroyed Check 
items are ACH entries in their own right. Such an item 
does not constitute the electronic presentment of a check. 

The initiation and acceptance of Destroyed Check Entries 
(XCK) is completely voluntary. A depository financial 
institution (collecting institution) may, but is not required 
to, initiate Destroyed Check entries to electronically 
collect lost/destroyed checks. Similarly, a receiving 
depository financial institution (paying institution) may, 
at its option, elect not to accept such entries. 

An XCK entry is limited to a number of specific criteria: 

•■'■.'■ XCK is limited to the collection of forward items 
only. 

• ■ . ■' Only specific types of checks are eligible: 

Items must be items within the meaning of 
Article 4 of the Uniform Commercial Code. 

- Items must be negotiable demand drafts drawn 
on or payable through a Participating DFI. 

Items must be in amounts less than $2,500. 

';■-'■■' Items must be lost, destroyed, or otherwise 
unavailable for presentment to a paying bank. 




Specific types of checks not eligible 
Destroyed Check entries include: 



as 



.'.'*.'' non-cash items 

* drafts drawn on the U.S. Treasury, Federal 
Reserve, or Federal Home Loan Banks 

* drafts drawn on state or local governments 
which are not payable through or at a bank 

* Postal Service money orders 

* Items payable in other than U.S. Currency 

* items in an amount equal to or greater than 
$2,500 

* return and rejected items 

•V The Destroyed Check application is limited to the 
loss of an entire cash letter only and is not for use 
with single lost items. 

B. LEGAL CONSIDERATIONS 

All liabilities and warranties are assumed by the financial 
institution that chooses to originate Destroyed Check 
entries. The ODFI is responsible for ensuring that: 

> it has good title to the item; 

all signatures on the item are authentic and 
authorized: 



OGI59 



SECTION IV -SPECIAL TOPICS 

CHAPTER IX -DESTROYED CHECK ENTRIES 



2005 OPERATING GUIDELINES 



•. the item has not been altered; 

• the item is not subject to a defense or claim; 

• ■. ■ . it has no knowledge of any insolvency; 

8 the XCK entry is accurate; and 

•■'.. the item has not been and will not be presented to the 
RDFI. 




C. ORIGINATION OF DESTROYED CHECK 

ENTRIESIXCKV 

Use of Destroyed Check entries by ODFIs (collecting 
institutions) is completely voluntary. If a collecting 
institution chooses to utilize the ACH to collect destroyed 
checks, the ODFI has the following responsibilities: 

Assumes all liability associated with XCK entries; 

• Proper formatting of XCK entries; 



May be required to produce a copy of the original 
item if the XCK entry is questioned, returned, or a 
copy of the check is requested at some future date; 
and 

May initiate XCK entries only under specific criteria 
and conditions. 



The words "NO CHECK" and "CHECK DESTROYED" 
must appear in the Company Entry Description and 
Company Name fields. This message will appear on the 
customer's statements and help identify the entry. 

D. RECEIPT OF DESTROYED CHECK ENTRIES 

(XCKV 

Acceptance of Destroyed Check Entries by the RDFI is 
completely voluntary. If the RDFI chooses not to accept 
any XCK entries, the RDFI will have to identify the 
entries by Standard Entry Class Code and return the items 
using Return Reason Code R33 - Return of XCK Entry. 

If the RDFI does choose to accept such entries, it could do 
so under the following scenarios: 

•'■ The RDFI could choose to allow the XCK entries to 
post with no special handling. Those entries that do 
not post would be returned. 

• The RDFI could choose to modify its software, 
particularly for corporate accounts, to handle XCK 
entries. This would allow the entries to "cross-over" 
from the ACH processing stream to the check 
processing stream for such purposes as account 
reconciliation, balance reporting, etc. 



RDFIs that choose to accept XCK entries should be aware 
that the NA CH A Operating Rules require them to print the 
contents of the Check Serial Number field on the 
consumer's monthly bank account statement. RDFIs 
should examine their statement reporting software to 
ensure this information is included as part of the monthly 
bank account statement 

Consistent with ACH record keeping requirements, the 
time period within which an RDFI can request a copy of 
a check for which an XCK entry is initiated is limited to 
six years. 

Following is a list of questions and answers which further 
explain the Destroyed Check application: 

1. What does the Destroyed Check application do? 



2. 



3. 



The Destroyed Check application allows a collecting 
institution to initiate ACH entries, in accordance with 
rules specific to this type of entry, for the purpose of 
electronically collecting checks which have been 
irretrievably lost or destroyed in the collection 
process. This application creates a new standard 
entry class code, XCK, for this type of entry. 

If a cash letter is destroyed, must an ODFI use this 
process to collect the items? 



No. Initiation and acceptance of Destroyed Check 
Entries is completely voluntary. A depository 
financial institution (collecting institution) may, but 
is not required to, initiate XCK entries to 
electronically collect lost or destroyed checks. 

What types of checks are eligible for Destroyed 
Check Entries? 

To be eligible for this type of transaction, an item 
must be (1) an item within the meaning of Article 4 
of the Uniform Commercial Code; (2) a negotiable 
demand draft drawn on or payable through a 
participating depository financial institution; (3) in an 
amount less than $2,500; and (4) lost, destroyed, or 
otherwise unavailable for presentment to a paying 
bank. 

Items such as noncash items or drafts drawn on a 
Federal Reserve Bank, a Federal Home Loan Bank, 
or the U.S. Treasury are ineligible for Destroyed 
Check Entries. Drafts drawn on a state or local 
government which are not payable through or at a 
bank are also ineligible, as are U.S. Postal Service 
money orders, items payable in a medium other than 
U.S. currency, items in an amount above $2,500, 
return items, and items which rejected during 
processing by the ODFI. 
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4. Why is a separate Standard Entry Class code 
necessary? 

A separate Standard Entry Class code (XCK) is 
needed to allow editing for Destroyed Check Entries 
as exceptions to regular ACH items and to 
communicate to RDFIs that special handling of such 
entries may be required. 

5. Is a Destroyed Check Entry a truncated check? 

No. A Destroyed Check Entry is considered to be a 
separate ACH item initiated in place of the lost or 
destroyed check. The entry does not constitute 
electronic presentment of the check, and no check 
will follow the ACH item. 

6. Is an XCK entry subject to Regulation E? 



No. Although a Destroyed Check Entry is an ACH 
item, because the payment was initiated by the 
consumer as a paper check it is not subject to 
Regulation E's rights and requirements. 

1, Is an RDFI required to accept Destroyed Check 
Entries? 



the ODFI within six years of the date of the XCK 
transaction. 

11. How long must the ODFI retain a copy of the 
original item? 

The ODFI must retain a copy of the item to which the 
Destroyed Check Entry relates for a period of six 
years from the date of the origination of the 
Destroyed Check Entry. 

12. Must the initiation of Destroyed Check Entries be 
authorized by the Originator and/or Receiver? 

XCK transactions are explicitly exempted from the 
authorization requirements of the NACHA Operating 
Rules. 

13. What happens if the original check is also paid? 

If the original check is paid in addition to the 
Destroyed Check Entry, the ODFI that initiated the 
Destroyed Check Entry may be held accountable for 
any resulting loss due to its breach of warranty. In 
this case, the RDFI should return the ACH 
transaction. 




No. An RDFI may determine at its sole discretion to 
return a Destroyed Check Entry. A Destroyed Check 
Entry may be returned by transmitting a return entry 
using return reason code R3 3. 

8. Does an RDFI assume any liability by accepting 
Destroyed Check Entries? 

No. The ODFI initiating Destroyed Check Entries 
warrants the appropriateness of such entries and 
assumes all liability related to the initiation of 
Destroyed Check Entries. An ODFI breaching any of 
the warranties indemnifies the RDFI against any and 
all resulting claims, demands, loss, liability, or 
expense, including attorneys' fees and costs. 

9. Why is the dollar limit for Destroyed Check Entries 
setat$2,500? 

A limit of $2,500 was chosen because, under 
Regulation CC, different handling requirements apply 
to checks with a value greater than $2,500. A similar 
limit has been set on Destroyed Check Entries to 
parallel the limit found in the check world. 

10. What does an RDFI do if a customer requires a copy 
of the destroyed check? 

The RDFI must send a written request to the ODFI 
asking it to provide a photocopy of the original 
check. Upon receipt of the written request, the ODFI 
is required to provide a copy of the check within 
thirty days, provided that the request is received by 



SECTION IV 
SPECIAL TOPICS 

CHAPTERX 

CROSS-BORDER PAYMENTS 

A INTRODUCTION 

This chapter is designed to provide ACH participants in 
the United States with an understanding of the cross- 
border ACH payment process, as prescribed by the 
NACHA Operating Rules and the Cross-Border 'Payment 
Operating Rules (see Section C-l within this Chapter). 
This framework for cross-border ACH payments was 
developed through the efforts of the NACHA Cross- 
Border Council, which was established in 1 993 to develop 
a standardized process for exchanging ACH payments 
across national borders. This undertaking was predicated 
upon the assumption mat by making the business rules and 
technical standards more uniform, the cross-border 
payment process would be more cost-effective, 
streamlined, predictable and accessible. 

The cross-border ACH payment framework consists of the 
following basic components: 

• NACHA Operating Rules 
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• Underlying Agreements 

• Gateway Operators 

In order to understand these components, it is useful to 
first describe the cross-border payment process. 

B. CROSS-BORDER PAYMENT PROCESS 

The cross-border payment process includes the origination 
of cross-border entries through an entity serving as an 
Originating Gateway Operator (OGO). The OGO is 
defined as a participant of a national payment system (i.e., 
an ACH Operator or an RDFI as defined by the NA CHA 
Operating Rules) or an entity acting as an agent for that 
participant, that (1) is capable of clearing and settling 
payments in that system, and (2) transfers transactions to 
a Receiving Gateway Operator (RGO) of a foreign 
payment system, in accordance with the Cross-Border 
Payment Operating Rules, After receiving cross-border 
entries from an ODFI, the OGO transmits the entries to a 
Receiving Gateway Operator (RGO) in the receiving 
country. The RGO subsequently transmits the entries into 
its national payments system for delivery to participating 
RDFIs. 

Figure 1 1 illustrates the origination of a cross-border entry 
by a U.S. ODFI to a Canadian RDFI. In this example, a 
U.S. business initiates a cross-border credit entry in the 
Consumer Cross-Border Payment (PBR) format to a 
consumer Receiver in Canada. The entry is cleared and 
settled via the ACH Network in U.S. Dollars. The OGO 
receives the entry from its ACH Operator. The OGO, 
which is either an ACH Operator or a U.S. RDFI, is 
deemed under the NACHA Operating Rules to have 
assumed the specific responsibilities and warranties of the 
RDFI with respect to cross-border transactions. Upon 
transfer of the entry to the Canadian RGO, the OGO 
agrees that settlement for the entry is irrevocable. This 
provision of the Cross-Border Payment Operating Rules 
is intended to contain credit risk and prevent the 
unwinding of transactions that have been exchanged via 
the receiving country's national payment system and 
posted to the account of the Receiver (or beneficiary). 
The format mapping and translation, foreign exchange 
conversion, and inter-gateway settlement for the entry 
occur in accordance with the underlying agreement 
between the OGO and RGO, as prescribed by the Cross- 
Border Payment Operating Rules. The RGO then 
transmits the entry via the Canadian Direct Clearing 
System (Automated Funds Transfer/Automated Clearing 
Settlement System) to the Canadian RDFI for posting to 
the Receiver's account. 

It is important to note that the roles and responsibilities of 
an OGO (for outbound payments) and of a RGO (for 
inbound payments) in the United States could be assumed 
by either an ACH Operator or a DFL Thus, the entity 
serving as the Gateway Operator could play multiple roles 
from a rules perspective. The diagram illustrates the 



cross-border payment credit process; however, debit 
entries may also be exchanged within this framework. 

Transmission of Cross-Border Entries 

Within the United States, cross-border entries are subject 
to the requirements of the NA CHA Operating Rules when 
transmitted between the ODFI and OGO and between the 
RGO and RDFI. Payment instructions initiated within the 
United States for beneficiaries abroad are transmitted by 
an originating company to its ODFI in the same manner as 
domestic payments, but with cross-border-specific data 
provided within the appropriate fields of the ACH 
records. The ODFI, in turn, transmits the cross-border 
payments to its ACH Operator with cross-border entries 
contained in a unique batch or batches within the file. 
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Special formatting and data requirements require that 
cross-border entries be batched separately from other 
ACH transactions. Specific coding requirements, as 
defined by the NA CHA Operating Rules, denote that the 
entries in that batch are cross-border, indicate the foreign 
exchange conversion methodology and the effective rate 
(as applicable), the currency denomination in which the 
entries were originated, the currency denomination in 
which the entries are to be received, and the country in 
which they are to be received. 
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To transfer the entries to the receiving country, the OGO 
transmits the payments to the RGO with which it is 
conducting business. The execution of the foreign 
exchange conversion, mapping between payment formats, 
storing of data, and settlement between the Gateway 
Operators occur in accordance with the Cross-Border 
Payment Operating Rules and their OGO/RGO 
Agreement. The RGO then transmits the entries into its 
national system. For cross-border payments inbound to 
the United States, this scenario works back through the 
ACH Operator to the RDFI and Receiver. 

Settlement 

Three instances of settlement occur for cross-border 
entries: (1) domestically in the origination country, (2) 
cross-border between Gateway Operators, and (3) 
domestically in the receiving country. Domestic 
settlement occurs in accordance with the rules and 
practices of the national payments system. Inter-Gateway 
Operator settlement is typically accomplished through 
correspondent banking relationships, employing wire 
transfer, S.W.I. FT. messages, due to/due from accounts, 
etc. 



Foreign Exchange 

The cross-border payment process provides flexibility to 
participants with respect to the foreign exchange 
component of cross-border payments. The terms and 
conditions for foreign exchange execution are stipulated 
by the OGO/RGO Agreement that is required by the 
Cross-Border Payment Operating Rules and the NACHA 
Operating Rules. The treatment of foreign exchange is 
then addressed in the separate agreements between the 
ODFI and the OGO, the Originator and the ODFI, and 
between the Originator and Receiver. 

Three types of foreign exchange scenarios are possible 
under this payment model for conducting cross-border 
payments: fixed exchange rate to variable exchange rate, 
variable exchange rate to fixed exchange rate, and fixed 
exchange rate to fixed exchange rate. For processing and 
reporting purposes, coding has been provided for each 
methodology within the technical specifications as defined 
by the NACHA Operating Rules. 

C. OPERATING RULES & AGREEMENTS 

The standardized legal and operational framework that 
was created to support the exchange of cross-border ACH 
payments is realized by bridging the national payment 
system rules of both the ODFI and RDFI in a cross-border 
transaction with a common set of rules governing the 
international transfer and processing of cross-border 
payments. This body of rules is called the Cross-Border 
Payment Operating Rules. The Cross-Border Payment 
Operating Rules provide a uniform platform for entities 
serving as Gateway Operators in various countries to 
interact. The Cross-Border Payment Operating Rules 



govern the business relationships between OGOs and 
RGOs. 

1. GROSS-BORDER PAYMENT OPERATING 
RULES (Effective February 1, 1999) 

ARTICLE I --SCOPE OF THE RULES ■'- The Cross- 
Border Payment Operating Rules apply to certain 
electronic Automated Clearing House (ACH) 
Transactions and transaction data exchanged between 
Gateway Operators subscribing to these rules. 

Article II -- Gateway Operators - 

Originating Gateway Operator (OGO) ■-An 

Originating Gateway Operator shall be a participant 
of a national payment system or an entity acting as an 
agent for that participant that (1) is capable of 
clearing and settling payments in that system, and (2) 
transfers transactions to a Receiving Gateway 
Operator of a foreign payment system, in accordance 
with the Cross-Border Payment Operating Rules. 

Receiving Gateway Operator (RGO) - A 

Receiving Gateway Operator shall be a participant of 
a national payment system or an entity acting as an 
agent for that participant that (1) is capable of 
clearing and settling payments in that system, and (2) 
receives transactions from an Originating Gateway 
Operator of a foreign payment system, in accordance 
with the Cross-Border Payment Operating Rules. 

Article III -- Compliance With Rules - Each 
participating Gateway Operator agrees to be bound 
by these rules and warrants that it is legally able to 
comply with all applicable requirements thereof. 

Article IV - Additional Bodies of Law - 

Gateway Operators shall comply with all additional 
laws, rules, regulations and court orders to which 
they are subj ect governing the exchange or effecting 
of transactions. 

Article V - OGO/RGO Agreement - An OGO 

and RGO shall have in place an agreement under 
which the parties agree to' (1) be bound by the Cross- 
Border Payment Operating Rules, (2) the terms and 
conditions for the time-value of execution, allocation 
of gains, losses and the assumption of risk for foreign 
exchange conversion, (3) the technical and 
operational responsibilities of each party, (4) the 
procedures for settlement between the parties, and (5) 
define what constitutes a commercially reasonable 
time frame with a clear definition of force majeure 
provisions. Unless otherwise agreed to, the 
relationship between the OGO and RGO shall be 
governed by the law of the State (country) of the 
RGO. 
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Article VI - Transaction Returns - The 
rights, obligations, and procedures associated with 
returning a cross-border transaction are determined 
by the national payment system operating rules of the 
receiving country of the original transaction. 

Article VII - Erroneous Transactions by 
Gateway Operators - An OGO may request an 
RGO to return or adjust an Erroneous Transaction 
initiated by the OGO. The RGO may, but is not 
obligated to, comply with such request. 

Article VIII « Irrevocability of Cross- 
Border Settlement - Upon funding of a 
transaction between Gateway Operators, settlement is 
irrevocable. 

Article IX - Processing, Scheduling & 
Timing - A Gateway Operator shall process and 
transfer a transaction to the appropriate subsequent 
party within a commercially reasonable time frame. 

Article X -- Record Retention - A Gateway 
Operator shall retain record of each transaction it 
processes for aperiod of one-year from the date that 
the transaction was transmitted or received. 



Operator, which shall indemnify another participant 
in connection with the transaction, (2) interest (at the 
short-term offer money market rate of the originating 
country for the originated currency) for the period 
during which the relevant Gateway Operator failed to 
perform its obligations under the terms of its 
OGO/RGO agreement, and (3) reimbursement of the 
original principal amount which the Gateway 
Operator failed to transfer in accordance with its 
OGO/RGO agreement regardless of any foreign 
exchange fluctuation, to the exclusion always of 
indirect or consequential damages. 

Article XVI -- Amendment of Gross-Border 
Payment Operating Rules '.- Any amendment 
(including any addition to or repeal) of these rules 
may be made as follows: by the vote at a meeting or 
by the written consent of the members of the Gross- 
Border Council in accordance with the Charter of the 
Cross-Border Council. 

Article XVII - Definition of Terms 

" ACH Transactions " or " Automated Clearing House 
Transactions " ■ - An electronic batch-oriented 
transaction. 



Article XI - Contingency Notification - In 

the event of a delay that affects its ability to process 
a transaction, the RGO shall duly notify the OGO of 
the transaction within a commercially reasonable time 
frame. 



" Charter " or " Cross-Border Council Charter " - A 
document which defines the nature, structure, 
procedures and policies governing the Cross-Border 
Council adopted August 1995, as amended from time 
to time. 



Article XII - Arbitration & Compensation - 

Unless otherwise agreed to, disputes arising out of or 
in connection with these rules and underlying 
agreements shall be resolved under the Rules of 
Arbitration of the International Chamber of 
Commerce. 

Article XIII -- Gateway Operator Technical 
Capabilities - A Gateway Operator is responsible 
for the exchange of transactions in accordance with 
applicable national payment system rules, and the 
exchange of transactions with other Gateway 
Operators in accordance with the OGO/RGO 
agreements. 

Article XIV - Gateway Operator Warranty 

- A Gateway Operator warrants to all other Gateway 
Operators that such transaction received from its 
national payment system or another Gateway 
Operator will be processed in compliance with these 
rules. 

Article XV -- Liability for Breaching 

Gateway Operator Warranty .— Each Gateway 
Operator breaching the warranty prescribed in 
Section XIV of these rules shall be limited to (1) 
transaction charges and fees charged by the Gateway 



" Cross-Border Council " or " Council "- The Cross- 
Border Council is an emancipated entity of the 
National Automated Clearing House Association 
(NACHA). 

" Erroneous Transaction " .- An erroneous transaction 
is a transaction that (1) is a duplicate of a transaction 
previously initiated by the OGO, (2) orders payment 
not intended to be credited or debited by the 
Originator, or (3) orders payment in an amount 
different than was intended by the Originator. 

" Gateway Operator " - Gateway Operator means 
either an Originating Gateway Operator or a 
Receiving Gateway Operator. 

" Originating Gateway Operator " or " OGO " - An 
Originating Gateway Operator shall be a participant 
of a national payment system or an entity acting as an 
agent for that participant, that (1) is capable of 
clearing and settling payments in that system, and (2) 
transfers transactions to a Receiving Gateway 
Operator of a foreign payment system, in accordance 
with the Cross-Border Payment Operating Rules. 

" Receiving Gateway Operator " or " RGO " - A 
Receiving Gateway Operator shall be a participant of 



OG164 



2005 OPERATING GUIDELINES 



SECTION IV- SPECIAL TOPICS 
CHAPTERX- CROSS-BORDER PAYMENTS 



a national payment system or an entity acting as an 
agent for that participant, that (1) is capable of 
clearing and settling payments in that system, and (2) 
receives transactions from an Originating Gateway 
Operator of a foreign payment system, in accordance 
with the Cross-Border Payment Operating Rules. 

" State " - State refers to a defined territory of 
governmental jurisdiction. 

" TransactionfsT - Transaction means an order or 
request for the (1) credit ofmoney to an account, (2) 
the debit of money from an account, or (3) a zero 
value entry. 

2. NATIONAL PAYMENT SYSTEM RULES 

The national payment system rules that are referred to in 
the cross-border payment process are the rules that govern 
the domestic ACH system (or its equivalent). In the 
United States, these are the NA CHA Operating Rules. For 
a cross-border entry that is being processed inbound into 
the United States and is transmitted via the ACH Network 
by an RGO for delivery to an RDFI in the United States, 
the rights and responsibilities of the RDFI are as 
stipulated by the NACHA Operating Rules. To facilitate 
the handling of cross-border entries, the legal framework 
has been crafted such that the RDFI treats a cross-border 
entry as it would a domestically-originated ACH entry. 
However, the SEC Codes used for cross-border entries 
allows the RDFI to identify a cross-border entry and 
provides certain data within that entry for customer 
service, reporting, and tracking purposes. 



Because of differences that exist between the two national 
payment systems involved in a cross-border transaction, 
or as a course of business of transacting outbound cross- 
border payments (i.e., those payments that are originated 
within the United States and destined for another country), 
certain provisions of the NACHA Operating Rules may 
not apply or additional responsibilities may be assumed 
by the Originating parties, as addressed in an agreement 
between the ODFI and OGO. These provisions were 
previously included in the Cross-Border Payment 
Operating Rules. However, the provisions, which are 
specific to the United States and the ACH Network, have 
been removed from the international body of rules and are 
currently addressed within Article Ten (Cross-Border 
Payments) as exceptions to the NACHA Operating Rules 
and in the service agreements between ODFIs and OGOs. 
The following provisions of the NA CHA Operating Rules 
do not apply to cross-border payments: 

• Receiver Authorization and Agreement 
■•'■■■■■ Authorization by Originator and Receiver 
e Revocation of Authorization 
V Termination of Authorization by Operation of Law 
•■'.■' Consumer A ccounts - Copy of Debit A uthorization 



All matters pertaining to the Receiver's authorization 
are governed by the applicable rules, laws, and/or 
regulations in the Receiver's country. Therefore, it is 
incumbent upon the U.S. Originator and its ODFI to 
understand and comply with those rules on a country- 
by-country basis. Under the warranties within the 
NA CHA Operating Rules assumed by the ODFI with 
respect to cross-border entries, the ODFI bears the 
responsibility and liability for compliance with this 
requirement 

Transmittal of Required Information 

The periodic statement requirements for outbound 
cross-border entries are governed by the applicable 
rules, laws, and/or regulations in the Receiver's 
country. Cross-border entries originated by an ODFI 
must, however, conform to the requirements of 
Appendix Two (ACH Record Format Specifications) 
of the NACHA Operating Rules. 



Reclamation Entries 
Prenotifications 




Reclamation and Prenotification entries as defined by 
the NACHA Operating Rules are typically not 
supported in other countries' payment systems and 
may not be transmitted to an OGO unless otherwise 
agreed to and instructed by the OGO. 

Reversing Files 
Reversing Entries 

The rules with respect to reversing files and reversing 
entries vary from country to country, and, in some 
countries, such transactions may be prohibited. An 
outbound cross-border entry may only be reversed 
pursuant to the NACHA Operating Rules up to the 
point of the OGO and prior to the transmission of the 
cross-border entries to the RGO. Although the 
Cross-Border Payment Operating Rules permit an 
OGO to request that an RGO return or adjust an 
erroneous transaction, the RGO is not obligated to 
comply with such a request. In situations where an 
outbound cross-border entry has been transmitted to 
the RGO for processing by the foreign receiving 
country and the OGO is unable to retrieve the entry, 
the ODFI and/or the Originator would be required to 
address any issues outside the ACH Network and 
seek resolution directly with the foreign RDFI or 
Receiver. 

Reinitiation of Returned Entries by Originators 

Provisions for reinitiating outbound cross-border 
entries that have been returned are determined by the 
national payment system rules of the foreign 
receiving country. The U.S. Originator and its ODFI 
must ensure that they understand and are compliant 
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with the rules governing reinitiation on a county-by- 
country basis. 



Consumer Accounts - Notice by Originator to 
Receiver of Variable Debits 




The requirements for an Originator to notify a 
Receiver when the amount of. a recurring debit entry 
varies are governed by the applicable rules, laws, 
and/or regulations of the foreign receiving country. 
The U.S. Originator and its ODFI must understand 
and ensure compliance with such rules on a country- 
by-country basis. Under the warranties within the' 
NACHA Operating Rules assumed by the ODFI with 
respect to cross-border entries, the ODFI bears the 
responsibility and liability for compliance with this 
requirement. 

Records 



At a minimum, the Originator of an outbound cross- 
border debit entry must retain and provide, upon 
request, the original or copy of the Receiver's 
authorization in accordance with the requirements of 
the NACHA Operating Rules. However, if the 
applicable rules, laws, and/or regulations in the 
foreign receiving country impose record retention 
requirements that are longer in duration, specify an 
additional form, or have additional requirements for 
providing the original or copy, the Originator must 
also comply with the requirements of the foreign 
receiving country. 

General Righ ts an d Obliga tions of RDF I 

The rights and obligations of the RDFI in a cross- 
border transaction are defined by the national 
payment system rules of the receiving country. The 
U.S. Originator and the ODFI of an outbound cross- 
border entry must understand the rights and 
responsibilities of foreign RDFIs and how these 
requirements differ from the requirements for RDFIs 
under the NACHA Operating Rules. 

Receipt and A vailability of Entries 

Availability of Entries and Entry Information, 

Crediting and Debiting of Entries 

Periodic Statements 

Notice to Receiver 

The foreign RDFI of an outbound cross-border entry 
is subject to the national payment system rules of the 
receiving country governing receipt, availability, 
crediting and debiting of entries, periodic statements, 
and notice to Receiver. The U.S. Originator and 
ODFI must be familiar with such rules and 
understand how they differ from those prescribed by 
the NA CHA Operating Rules. 



Liability of RDFI for Benefit Payments 

The liability of a foreign RDFI for benefit payments, 
if applicable, is determined by the national payment 
system rules of the foreign receiving country. The 
U.S. Government and its disbursing agents must 
ensure that they are familiar with the treatment of 
benefit payments, RDFI liability, etc., within the 
foreign receiving country and establish procedures to 
manage such matters outside the scope of the NA CHA 
Operating Rules. 

Return of Entries 



The return of entries by the RDFI of an outbound 
cross-border entry is subject to the requirements of 
the national payment system rules of the foreign 
receiving country. The U.S. Originator and ODFI 
must be familiar with the rules governing returns for 
each country to which cross-border entries are 
transmitted. 



Dishonor of Return Entries 



It is important to note that many countries do not 
provide for the dishonor of a return entry within their 
national payment system rules. Instead, such matters 
are handled outside the scope of their rules directly 
between the sending and receiving institutions. In 
accordance with the NACHA Operating Rules, aU.S. 
ODFI may dishonor the return of an outbound cross- 
border entry, provided that (1) it is permitted to do so 
by the payment system rules of the receiving country 
of the original outbound entry, and (2) the return does 
not comply with the payment system rules of the 
receiving country of the original outbound cross- 
border entry or the return contains incorrect 
information, does not include all information required 
by the NACHA Operating Rules, or otherwise fails to 
comply with the requirements of the NA CHA 
Operating Rules. It 'the payment system rules of the 
foreign receiving country permit the dishonor of a 
return, the ODFI must be prepared to determine 
whether the return was transmitted by the foreign 
RDFI in accordance with the foreign payment system 
rules. If the return contains incorrect or incomplete 
information, or otherwise fails to comply with the 
requirements of the NACHA Operating Rules, the 
dishonor is limited in scope between the ODFI and 
the OGO. It is recommended that the OGO take 
steps to remedy the entry, regardless of the presence 
or lack of dishonor capability within the foreign 
payment system rules. 

Notification of Change 

Notification of Change entries are not typically 
supported by the payment system rules of other 
countries. Therefore, unless otherwise agreed to with 
the OGO, the U.S. ODFI of an outbound cross-border 
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entry will not receive such a transaction. U.S. 
RDFIs, however, may transmit NOCs in response to 
inbound cross-border entries in accordance with the 
requirements of the NA CHA Operating Rules. In 
such cases, it is recommended that the U.S. RGO take 
steps to convey the NOC data to the foreign ODFI. 

• Accountability for Entries 

The foreign RDFI of an outbound cross-border entry 
is subject to the national payment system rules of the 
foreign receiving country. 

Stop Payment Affecting Consumer Accounts 

• Stop Payment Affecting Non-Consumer Accounts 

• Receiver's Right to Recr edit 

• Adjustment Entries 

A foreign RDFI of an outbound cross-border entry 
will apply rules governing stop payment orders, 
adjustment entries, and the Receiver's right to 
recredit in accordance with the payment system rules 
of the foreign receiving country. The U.S. Originator 
and ODFI must ensure that they are familiar with the 
rules governing such transactions for each country to 
which cross-border entries are transmitted. 

•'.'■ Minimum Description Standards 

The NA CHA Operating Rules addressing minimum 
description standards and the application of 
Regulation E apply only to financial institutions 
within the U.S. The national payment system rules of 
the receiving foreign country apply to the handling of 
all outbound cross-border entries. 

Agreements 

An OGO and RGO shall have in place an agreement under 
which the parties agree to (1) be bound by the Cross- 
Border Payment Operating Rules, (2) the terms and 
conditions for the time- value of execution, allocation of 
gains, losses and the assumption of risk for foreign 
exchange conversion, (3) the technical and operational 
responsibilities of each party, (4) the procedures for 
settlement between the parties, and (5) define what 
constitutes a commercially reasonable time frame with a 
clear definition of force majeure provisions. Unless 
otherwise agreed to, the relationship between the OGO 
and RGO shall be governed by the law of the State 
(country) of the RGO. 

The OGO/RGO Agreement defines certain aspects of the 
OGO/RGO business relationship and also binds the two 
parties to the common body of rules. In order to initiate 
a cross-border entry for processing by an OGO, an ODFI 
must also have an agreement in place with that OGO. The 
ODFI/OGO agreement should also address the handling 
of foreign exchange and other business and operational 
aspects of the relationship, bind the OGO to the Cross- 



Border Payment Operating Rules, and address cross- 
border AGH service and responsibility aspects that are not 
explicitly addressed in the NACHA Operating Rules. 
Likewise, the ODFI should incorporate appropriate 
operational and legal aspects critical to its OGO 
relationship in its agreement with an Originator. An 
Originator of a cross-border AGH payment enters into an 
agreement with a Receiver in accordance with the national 
payment system rules of that Receiver's country. 

P. CROSS-BORDER PAYMENT TECHNICAL 
STANDARDS 

Cross-border payments are transmitted using the 
Consumer Cross-Border Payment (PBR) and Corporate 
Cross-Border Payment (CBR) Standard Entry Class 
(SEC) Codes. The CBR SEC Code is used for the 
transmission of corporate cross-border payment entries, 
and the PBR SEC Code for the transmission of consumer 
cross-border payment entries. These SEC Codes allow 
cross-border transactions to be readily identified by 
financial institutions so that they may apply special 
handling requirements for cross-border payments, as 
appropriate. These formats also enable ACH participants 
to transmit and receive detailed information that is unique 
to cross-border payments. 

A unique Company/Batch Header Record is used to 
convey information relating to foreign exchange, 
origination and destination currencies, and destination 
country. Each Entry Detail Record is accompanied by 
one Addenda Record, within which information relating 
to the foreign receiving DFI, foreign payment amount, 
foreign trace number, and foreign receiver's account 
number is conveyed. 

In the CBR/PBR Company/Batch Header Record, fields 
4, 5, and 6 provide information on the foreign exchange 
process. Field 4 (Foreign Exchange Indicator) indicates 
whether the item is a fixed-to-fixed (FF), fixed- to-variable 
(FV), or variable-to-fixed (VF) transaction. The field will 
contain a 1 , 2, or 3, indicating the use of a Foreign 
Exchange Rate (1), a Foreign Exchange Reference 
Number (2), or it may be space filled (3). The codes in 
the Foreign Exchange Reference Indicator (Field 5) are 
used to indicate the content of the Foreign Exchange 
Reference (Field 6). When coding Field 5, if the Foreign 
Exchange Indicator Field contains U VF" or "FV," then 
Field 5 should have a 1, 2, OR 3, and Field 6 will contain 
a foreign exchange rate, a foreign exchange contract 
number, or it may be space filled. If the foreign exchange 
information is not available at the time the batch is 
created, Field 5 will have a 3 and Field 6 will be space 
filled. 

Additionally, in the Service Class Code Field (Field 2) of 
the Company/Batch Header Record, depending on the 
cross border operator arrangement, you may be required 
to segregate debits and credits into separate batches. The 
Service Class Code for Debits is 225 and a credit is 220. 
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ACH participants should be aware that unique 
Company/Batch Header Records and Addenda Records 
are used to accommodate the return of cross-border 
payments. However, the existing Entry Detail Record for 
return entries is used to accommodate cross-border 
information. Similarly, a new Company/Batch Header 
Record is used for cross-border dishonored returns, 
contested dishonored returns, NOCs, and refused NOCs. 
The existing Entry Detail Records and Addenda Records 
for dishonored returns, contested dishonored returns, 
NOCs, and refused NOCs are used to accommodate cross- 
border payments. Please refer to Appendix Two (ACH 
Record Format Specifications) of the NACHA Operating 
Rules for the ACH record format specifications for CBR 
and PBR entries. 

E. CROSS-BORDER REFERENCE 

INFORMATION 

ISO Codes : 

ISO Country and Currency code lists are available for 
purchase from the International Organization for 
Standardization (ISO). The web address for the ISO is 
www.iso.ch. Currently, cross-border payments are being 
processed between the US and Canada. Appropriate ISO 
codes for Canada are: 



Currency: CAD or USD 
Country: CA 



Foreign ACH Rules Contacts : 

Australia 

Australian Payments Clearing Association (APCA) 

Level 24, 25 Bligh Street 

Sydney NSW 2000 

Australia 

www.apca.com.au 

Canada 

Canadian Payment Association 

1212-50 O'Connor St. 

Ottawa, ON K1P6L2 

Canada 

1(613)238-4173 

www.cdnpay.ca 



France 

GSIT 

31 RuedeBerri 

Cedex08 

Paris 75408 France 

www.gsit.fr 



Norway 

Bankenes Betalingssentral AS BBS 

Haavard Martinsens vei 54 

Postal Address N-0045 

Oslo 

Norway 

www.bbsas.no 

Sweden 

Bankgirocentralen BGC AB 
Palmfeltsvagen 5 A 
Stockholm 105 19 
Sweden 
www.bgc.nu 

Switzerland 

Telekurs SIC, Ltd. 

Hardturmstrasse 201 

CH8021 

ZurichCH8021 

Switzerland 

www.telekurs.com 

United Kingdom 

BACS,Ltd. 

De Havilland Road Edgeware 

Middlesex HA8 5QA 

United Kingdom 

www.bacs.co.uk 
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CHAPTER XI 

RE-PRESENTED CHECK ENTRIES 

A. INTRODUCTION 

The NACHA Operating Rules permit the ACH Network 
to be utilized to transmit a Single Entry ACH debit 
transaction to re-present a paper check after the paper 
check has been returned for insufficient or uncollected 
funds. This chapter addresses issues relating to the 
origination and receipt of Re-presented Check Entries. 

B. LEGAL FRAMEWORK 

Re-presented Check Entries (RCK entries) are subject to 
applicable NA CHA Operating Rules, the Uniform 
Commercial Code ; and Federal Reserve Regulation CC. 
These entries are not, however; subject to the Electronic 
Funds Transfer Act or Regulation E. The legal 
framework for Re-presented Check Entries is premised on 
the fact that the origin of each re-presented check entry is 
a paper check that has been dishonored. Transfers of 
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funds that were originated by a check, draft, or similar 
paper instrument are specifically excluded from coverage 
under the EFTA (15 U.S.C. 1693a(6)) and Regulation E 
(12 G.RR. 2053(c)(1)). Accordingly, if a Re-presented 
Check Entry is treated as a check transaction for purposes 
of the EFTA and Regulation E, it follows that the UCC 
and Regulation CC should continue to be the bodies of 
law that govern the rights and responsibilities of the 
parties involved with that payment, even though it has 
been converted to electronic form. 

C. ELIGIBLE ITEMS 



A Re-presented Check Entry is considered to be a 
presentment notice for purposes of Revised Article 4 of 
the Uniform Commercial Code (1990 Official Text). To 
that end, the receipt of a Re-presented Check Entry 
constitutes presentment of the item in accordance with 
Article 4-110, and the return of the Re-presented Check 
Entry constitutes notice of dishonor or non-payment of the 
item in accordance with Article 4-301 . The provisions of 
the NA CHA Operating Rules that are applicable to Re- 
presented Check Entries are in accordance with the 
Commentary provisions set forth in 12 C.F.R. Part 229.37 
of Federal Reserve Regulation CC. 

To be eligible to be transmitted as an RCK entry, an item 
must: 

• be an item within the meaning ofRevised Article 4 of 
the Uniform Commercial Code ( 1 990 Official Text) ; 

• be a negotiable demand draft drawn on or payable 
through or at a participating DFI, other than a Federal 
Reserve Bank or Federal Home Loan Bank; 

• contain a pre-printed serial number; 

• be in an amount less than $2,500; 

• ■ indicate on the face of the document that it was 

returned for insufficient or uncollected funds; 

' • . be dated less than 1 80 days from the date the entry is 
transmitted to the RDFI; 

.• be drawn on a consumer account; and 

•■■: must have been previously presented (a) no more 
than twice in paper form, if the entry is an initial 
RCK entry; or (b) no more than once in paper form 
and no more than once as anRCK entry, if the entry 
is a reinitiated RCK entry. 

Items that are ineligible for transmission as RCK entries 
include, but are hot limited to: 

:• non-cash items (as defined by Section 229.2(u) of 
Federal Reserve Regulation CC); 



.'•■.-.' : ■' drafts drawn on the Treasury of the United States, a 
Federal Reserve Bank, or a Federal Home Loan 
Bank; 

• drafts drawn on a state or local government that are 
not payable through or at a Participating DFI; 

• United States Postal Service money orders; 

• items payable in a medium other than United States 
currency; 

• items that are third-party items (e.g., the payee 
endorses a check over to a third party who also 
endorses the check); and 

• demand drafts and third-party drafts that do not 
contain the signature of the Receiver (e.g., the drawer 
does not sign a check but authorizes another party to 
debit his account via a draft). 

D. OBLIGATIONS OF ORIGINATORS 

1. AGREEMENTS WITH ODFIs 

Originators choosing to utilize the ACH Network to 
collect checks that have been returned for insufficient or 
uncollected funds should consider modifications to their 
agreements with their ODFIs to address the origination of 
RCK entries. These modifications could, for example, 
address the extent to which the Originator and ODFI 
would share liability for the following warranties as they 
apply to the origination of these transactions: 

» the ODFI has good title to the returned item; 

• all signatures on the item are authentic and 
authorized; 

• ■ . the item has not been altered; 

• ■■■ the item is not subject to a defense or claim; 

• it has no knowledge of any insolvency; 

• ■ '■ the re-presented check entry accurately reflects the 
■'■■'■'■ item; 

• the item has not been and will not be presented; 

• the information encoded after issue in magnetic ink 
on the item is correct; 

• any restrictive endorsement placed on the item is void 
or ineffective; and 

•■■'.■' the ODFI will provide the RDFI with a copy of the 
front and back of the item within ten banking days of 
the RDFFs written request for a copy. 

2. NOTICE REQUIREMENT 




An RCK entry is authorized by the consumer through the 
provision by the Originator of a notice to the check writer 
and the subsequent receipt of the consumer's check by the 
Originator. Originators of RCK entries must provide 
notice to the check writer, prior to receiving the item to 
which the RCK entry relates, informing the check writer 
that his returned check may be collected electronically if 
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the check is returned for insufficient or uncollected funds. 
The manner in which the Originator provides notice to the 
check writer is not prescribed by the NACHA Operating 
Rules. However, the notice must clearly and 
conspicuously state the terms of the Re-presented Check 
Entry policy. It is recommended that notice provided at 
the point-of-sale be clearly displayed on a sign at the 
point-of-sale, and that notice provided by a billing firm 
(i.e., utility company or credit card company which issues 
a bill for payment) be clearly displayed on or with the 
monthly billing statement. 

Originators should be aware that, to protect both the check 
writer and the RDFI, a check writer will be able to sign a 
written statement under penalty of perjury and be 
recredited for the amount of the entry if the required 
notification by the Originator is not provided. The RDFI, 
in turn, will be able to return the RCK entry by 
transmitting the return entry to its ACH Operator by its 
deposit deadline for the return entry to be made available 
to the ODFI no later than the opening of business on the 
banking day following the sixtieth calendar day following 
the settlement date of the RCK entry. 

3. RESTRICTIVE ENDORSEMENTS 



Any restrictive endorsement (e.g., "For Deposit Only") 
placed on the item by the Originator or its agent is void or 
ineffective when the item is presented as a re-presented 
check entry. 

4. COLLECTION FEES 

Re-presented Check Entries may be originated only for 
the face amount of the check. No collection fees may be 
added to the amount of the item when it is transmitted as 
an ACH entry. 

An Originator desiring to use the ACH Network to collect 
a service fee must originate a separate PPD, TEL, or 
WEB debit entry to the consumer's account and must 
follow all rules governing the specific transaction used, 
including having first obtained the consumer's 
authorization for such an entry in the manner specified by 
the NACHA Operating Rules. 



Some Originators may desire to place an authorization 
stamp on the check being used for the payment of goods 
or services in order to collect a returned check fee in the 
event that the check is returned for insufficient or 
uncollected funds. In order for this practice to be 
compliant with the NACHA Operating Rules, the 
following requirements must be met: 

• An authorization placed on the check must be signed 
(not initialed). This signature must stand alone, i.e., 
the authorization language for the ACH debit entry 
must not be stamped in close proximity to the 
maker's signature on the check. The signature must 
clearly relate to the authorization language itself. 



• The authorization on the check must be identifiable 
as an ACH debit authorization and must clearly and 
conspicuously state its terms (i.e., the print cannot be 
so small or smeared that a consumer would be unable 
to easily read the authorization and understand its 
terms). 

• The authorization on the check must contain 
information that explains how the consumer may 
revoke the authorization. 

• The Originator must provide the consumer with an 
electronic or hard copy of the authorization. 

•■:■■. The Originator must retain the original or a microfilm 
(or its equivalent) copy of the authorization for two 
years from the termination or revocation of the 
authorization. 

Authorization language, if stamped on the back of the 
check, should be in the endorsement space provided and 
not lower on the check. Before stamping the back of a 
check with anything other than an endorsement, 
Originators must ensure that they understand and are in 
compliance with both the NACHA Operating Rules and all 
regulations that govern the collection of checks. 

5. NUMBER OF PRESENTMENTS 

Originators may transmit a re-presented check entry no 
more than twice after the first return of a paper item, and 
no more than once after the second return of a paper item. 



6, RETENTION OF COPY OF ITEM 

The Originator must retain a copy of the front and back of 
the item (check) to which the RCK entry relates for seven 
(7) years from the settlement date of the RCK entry. 
When requested to do so by the ODFI, the Originator 
must provide a copy of the front and back of the check to 
the ODFI for its use or for the use of the RDFI requesting 
the information. If the check has been finally paid, this 
must be indicated on the copy. 

7. RETURN OF RE-PRESENTED CHECK 
ENTRIES 

Originators should be aware that RCK entries may be 
returned for a variety of reasons. For the majority of RCK 
entry returns, the RDFI must transmit the return entry to 
its ACH Operator by midnight of the second banking day 
following the banking day of receipt of the RCK entry. 

However, Originators should be aware that, for RCK 
entries for which ( 1 ) the Receiver had placed a stop 
payment order on the item to which the RCK entry relates, 
(2) the required notice stating the re-presented check entry 
policy was not provided by the Originator, (3) the check 
is ineligible, (4) all signatures on the check are not 
authentic or authorized, or the check has been altered, (5) 
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the amount of the entry was not accurately obtained from 
the item, or (6) both the RCK entry and the item to which 
the RCK entry relates have been presented for payment, 
the RDFI will be able to transmit a return entry to its ACH 
Operator by its deposit deadline for the return entry to be 
made available to the ODFI no later than the opening of 
business on the banking day following the sixtieth 
calendar day following the settlement date of the RCK 
entry. With the exception of returns due to stop payment 
on the original item, the Receiver is required to provide 
the RDFI with a written statement under penalty of 
perjury stating the reason for the return as described 
above. (Note: For additional information on written 
statements under penalty of perjury, refer to the RDFIs 
chapter in Section II of these Guidelines.) 

F RESPONSIBILITIES OF ODFIs 

■ 1. WARRANTIES AND LIABILITIES 

In addition to all other ODFI warranties contained within 
the NACHA Operating Rules, each ODFI that chooses to 
transmit RCK entries on behalf of its Originators also 
warrants to each RDFI, ACH Operator, and ACH 
Association that: 

• it has good title to the returned item; 

• all signatures on the item are authentic and 
authorized; 

• the item has not been altered; 

• the item is not subject to a defense or claim; 

• it has no knowledge of any insolvency; 

the re-presented check entry accurately reflects the 
■.'■■■■ item; 
•.-.'■.■ the item has not been and will not be presented; 

• the information encoded after issue in magnetic ink 
on the item is correct; 

• any restrictive endorsement placed on the item is void 
or ineffective; and 

• the ODFI will provide the RDFI with a copy of the 
front and back of the item within ten banking days of 
the RDFI' s written request for a copy. 

ODFIs should consider modifications to their agreements 
with their Originators that choose to utilize the ACH 
Network to collect checks that have been returned for 
insufficient or uncollected funds. These modifications 
should address issues such as whether the Originator is 
willing to accept some of the liability for the ODFI's 
warranties relating to the origination of these transactions, 
as listed above, on the Originator's behalf. 

2. FORMATTING REQUIREMENTS 

As with all ACH entries, ODFIs must ensure that; prior to 
transmission to the ACH Operator, RCK entries comply 
with all technical specifications and formatting 
requirements in accordance with the NACHA Operating 
Rules. ODFIs must ensure that: 



• the description "REDEPCHECK" appears within the 
Company Entry Description Field of the 
Company/Batch Header Record; 

•'.'■ the original payee on the face of the check appears 
within the Company Name Field of the 
Company/Batch Header Record (Note: Minor 
variations in how the payee's name appears in this 
field are acceptable); and 

V the Check Serial Number of the check to which the 
re-presented check entry relates is placed within the 
Check Serial Number Field of the RCK Entry Detail 

Record. 

3. RETURN OF RE-PRESENTED CHECK 

/ENTRIES 

ODFIs should be aware that RCK entries may be returned 
for a variety of reasons. For the majority of RCK entry 
returns, the RDFI must transmit the return entry to its 
ACH Operator by midnight of the second banking day 
following the banking day of receipt of the RCK entry. 

However, ODFIs should be aware that, for RCK entries 
for which (1) the Receiver had placed a stop payment 
order on the check to which the re-presented check entry 
relates, (2) the required notice stating the re-presented 
check entry policy was not provided by the Originator, (3) 
the check is ineligible, (4) all signatures on the check are 
not authentic or authorized, or the check has been altered, 
(5) the amount of the entry was not accurately obtained 
from the item, or (6) both the RCK entry and the item to 
which the RCK entry relates have been presented for 
payment, the RDFI will be able to transmit a return entry 
to its ACH Operator by its deposit deadline for the return 
entry to be made available to the ODFI no later than the 
opening of business on the banking day following the 
sixtieth calendar day following the settlement date of the 
RCK entry. With the exception of returns due to stop 
payment on the original check, the Receiver is required to 
provide the RDFI with a written statement under penalty 
of perjury stating the reason for the return as described 
above . (Note: For additional information on written 
statements under penalty of perjury, refer to the RDFIs 
chapter in Section II of these Guidelines.) 

4. RETENTION OF COPY OF ITEM 

ODFIs should be aware that an RDFI that receives an 
RCK entry may send the ODFI that transmitted the entry 
a written request for a copy of the front and back of the 
item (check) to which the RCK entry relates. An RDFI 
requesting a copy of the check to which the RCK entry 
relates must send a written request to the ODFI within 
seven years of the settlement date of the RCK entry. 
Upon receipt of the RDFFs written request, the ODFI 
must provide a copy of the front and back of the check to 
the RDFI within ten banking days. ODFIs will need to 
establish policies and procedures with their Originators to 
obtain a copy of a check to which an RCK entry relates 
when requested to do so by an RDFI. 
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F. RECEIPT OF RE-PRESENTED CHECK 
-■■ ENTRIES 

1. RETURN OF A RE-PRESENTED CHECK 

ENTRY 

RCK entries may be returned for a variety of reasons For 
the majority of RCK entry returns, the RDFI must transmit 
a return entry to its ACH Operator by midnight of the 
second banking day following the banking day of receipt 
of the RCK entry. (The RCK entry is considered to be 
received by the RDFI when the RCK entry is made 
available to the RDFI by its ACH Operator.) This return 
time frame is different from the typical ACH return time 
frame because of the need to be consistent with return 
time frames under the Uniform Commercial Code (UCC). 

If a financial institution currently initiates all returns by 
midnight (RDFI's local time) of the banking day following 
the settlement date; this difference in return time frames 
should not affect the institution's processing of return 
entries. If, however, the RDFI initiates returns after 
midnight of the banking day following the settlement date, 
me RDFI will need to modify its procedures to ensure that 
RCK entry returns are transmitted to its ACH Operator by 
midnight of the second banking day following the banking 
day of receipt of the RCK entry. This is also the 
applicable return time frame for RCK entries transmitted 
to RDFIs that (1) are located in a state that has not 
adopted Revised Article 4 of the Uniform Commercial 
Code (1990 Official Text) and have not revised their 
customer agreements to allow for electronic presentments, 
and (2) are located in a state that has a statute that requires 
the RDFI to return all canceled checks to the Receiver in 
the periodic statement for a specific type of account. 

In certain circumstances, however, RDFIs have an 
extended time frame in which to return RCK entries. For 
the reasons noted below, an RDFI may transmit a return 
of an RCK entry to its ACH Operator by its deposit 
deadline for the return entry to be made available to the 
ODFI no later than the opening of business on the banking 
day following the sixtieth calendar day following the 
settlement date of the RCK entry: 

( 1 ) The Receiver had placed a stop payment order on the 
cheek to which the RCK entry relates. 

(2) The Receiver states that the required notice stating 
the re-presented check entry policy was not provided 
by the Originator. 

(3) The Receiver states that the check was ineligible for 
collection as an RCK entry. 

(4) The Receiver states that all signatures on the check 
are not authentic or authorized, or the item has been 
altered. 



(5) The Receiver states that the amount of the entry was 
not accurately obtained from the item. 

(6) The Receiver states that both the RCK entry and the 
item to which the RCK entry relates have been 
presented for payment. 

In each of the scenarios noted above, the Receiver may 
request that his RDFI immediately recredit his account 
and return the entry to the Originator. With the exception 
of returns due to stop payment on the original check, the 
RDFI must obtain from me Receiver a written statement 
under penalty of perjury, in the form required by the 
RDFI, in which the Receiver states the reason for the 
return as described above. (Note: For additional 
information on written statements under penalty of 
perjury, refer to the RDFIs chapter in Section II of these 
Guidelines.) 

2. STOP PAYMENT ON A RE-PRESENTED 
CHECK ENTRY 

As with other types of ACH entries, a Receiver may 
request that a stop payment order be placed on an RCK 
entry. To be consistent with me UCC, a minor variation 
from current NACHA Operating Rule provisions applies 
to stop payment orders placed on RCK entries that 
requires the stop payment order to be placed in such time 
that the RDFI has a reasonable opportunity to act upon the 
stop payment order prior to acting on me debit entry. 

"3. COPY OF CHECK 

An RDFI that receives an RCK entry may send the ODFI 
that transmitted the entry a written request for a copy of 
the front and back of the check to which the RCK entry 
relates. An RDFI requesting a copy of the check to which 
the RCK entry relates must send a written request to the 
ODFI within seven years of the settlement date of the 
RCK entry. Upon receipt of the RDFI's written request, 
the ODFI must provide a copy of the front and back of the 
check to the RDFI within ten banking days. 

4. STATEMENT REQUIREMENTS 

RDFIs must provide the Check Serial Number on the 
consumer's monthly statement for all RCK entries. 
RDFIs need to ensure that this information is provided on 
the consumer's statement. 
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A; INTRODUCTION 

The NA CHA Operating Rules support an application that 
enables Originators (i.e., merchants, billers, etc.) to 
initiate a Single-Entry ACH debit entry to a Receiver's 
account for in-person purchases made at the point-of- 
purchase. This application, which is based on a written 
authorization and account information drawn from a 
source document (check) obtained from the consumer at 
the pomt-of-purchase, provides Originators with an 
alternative to accepting consumers' checks as the method 
of payment. This chapter addresses issues relating to the 
origination and receipt of Point-of-Purchase Entries (POP . 

A POP entry is a Single-Entry ACH debit used by 
Originators as an alternative method of payment for goods 
or services purchased in person. These one-time debit 
entries are initiated by the Originator to the consumer's 
account based on a written authorization and account 
information drawn from a source document (a check) 
obtained from the consumer at the point-of-purchase. To 
initiate a POP entry, the consumer must present a check or 
sharedraft that has not been previously voided or 
negotiated to the Originator. The Originator uses a check 
reading device to capture the MICR information from the 
check (i.e., routing number, account number, and serial 
number), which will be used by the Originator to generate 
a debit entry to the consumer's account. The Originator 
may not key enter the MICR information from the check, 
nor may the Originator key enter the MICR information 
after the check reader has captured this data. The 
Originator then key enters the amount of the transaction, 
after which an authorization will be provided to the 
consumer to sign, authorizing the debit to his account. 
The Originator must provide to the consumer (1) the 
consumer's source document, which the Originator has 
voided, (2) a copy of the consumer's authorization, and 
(3) a receipt containing specific information relating to the 
purchase. 

B. LEGAL FRAMEWORK 

POP entries are subj ect to the requirements of the NA CHA 
Operating Rules, the Electronic Fund Transfer Act, and 
the Federal Reserve's Regulation E. POP entries are 
considered to be ACH entries from start to finish, with the 
consumer's check used by the Originator solely as a 
source document for the consumer ' s routing and account 
number information. Such transactions are not considered 
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to be truncated checks and do not fall under the 
requirements of check law or the Uniform Commercial 
Code for the following reasons: 

(1) the check is not accepted by the merchant as a 
negotiable instrument; and 

(2) the check is not negotiated by the merchant or 
accepted into the check collection system. 

C. OBLIGATIONS OF ORIGINATORS 

1. AGREEMENTS WITH ODFIs 

Originators choosing to utilize the ACH Network for POP 
transactions should consider modifications to their 
agreements with their ODFIs to address the origination of 
these entries. These modifications should address the 
extent to which the Originator and ODFI will share 
liability for point-of-purchase transactions and should 
define any specific processing obligations relating to such 
transactions. 

2. AUTHORIZATION REQUIREMENT 

Originators of POP entries must obtain the consumer's 
written authorization prior to initiating a debit entry under 
this application. Although the NACHA Operating Rules 
do not prescribe specific authorization language for the 
point-of-purchase application, the authorization must 
conform to the requirements of the NA CHA Operating 
Rules, which require that the authorization ( 1 ) be in 
writing, signed or similarly authenticated by the Receiver, 
(2) be readily identifiable as an ACH debit authorization, 
and (3) clearly and conspicuously state its terms. It is 
strongly recommended that authorization language for 
point-of-purchase entries specifically state that the check 
will not be processed. This will assist consumers in 
understanding the nature of the transaction. Originators 
must provide a copy of the authorization to the consumer 
as required by the NACHA Operating Rules . 

Unlike authorization requirements for most consumer 
debit entries, Originators of point-of-purchase entries 
need not include on the authorization the method by 
which the consumer must revoke the authorization, as 
these entries can not be returned using Return Reason 
Code R07 (Authorization Revoked). Consumers retain 
their rights to stop payment on the ACH entry (R08) or to 
have it returned as unauthorized/improper (RIO) when 
appropriate. 

3. SOURCE DOCUMENTS 

Acceptable Source Documents 

Originators may only accept a check or sharedraft as a 
source document for a point-of-purchase debit entry if the 
check or sharedraft: 

has not been previously negotiated; 
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• ■ ■ ' has not been previously voided; 

contains a pre-printed serial number; and 
is drawn on a consumer account. 

Unacceptable Source Documents 




Checks that may not be used as source documents for 
point-of-purchase entries include: 

corporate checks; 
third-party checks; 

• credit card checks; 

obligations of a financial institution (e.g., cashier's 

checks, money orders, traveler's checks, official 

checks, etc.); 

checks drawn on the Treasury of the United States, a 

Federal Reserve Bank; or a Federal Home Loan 

Bank; 
•checks drawn on a state or local government; or 
° checks payable in a medium other than United States 

currency. 

4. RECEIPT REQUIREMENTS 

Originators must, at the point-of-purchase, provide 
Receivers with a receipt that contains the following 
minimum amount of information: 

■•:'■: Originator name (merchant); 

company (merchant)/third-party service provider 

telephone number; 
•■■ date of transaction; 
.• transaction amount; 

source document check serial number; 

• merchant number (or other unique number that 
identifies the location of the transaction); 

• Terminal City; and 
•■ Terminal State. 

Note: The Federal Reserve Board's Official Staff 
Commentary on Regulation E requires the inclusion of 
terminal location information on the receipt provided to 
the consumer at the point of purchase. When a POS 
terminal is used to capture data electronically to initiate an 
EFT, the Regulation E Official Staff Commentary 
considers the POS terminal to be an electronic terminal, 
even if no access device is used, such as when a check is 
used to capture information to initiate a one-time EFT. As 
a result, when a check is used as a source document at the 
point of purchase and run through a terminal to read the 
MICR information, as is the case with POP entries, it is 
necessary to ensure compliance with Regulation E's 
requirements for electronic terminals, which mandate the 
inclusion of the terminal location on the receipt for POP 
entries. 

It is also recommended, but not required, that the 
Originator provide the following information on the 
receipt provided to the Receiver: 



•" merchant address; 

merchant identification number; 

Receiver's financial institution routing number; 

• Receiver's truncated account number; 

• ■ Receiver's truncated identification number; and 

• transaction reference number. 

Originators must be aware that the Receiver's complete 
account number and complete identification number are 
not permitted to be placed on the receipt. At the 
Originator's discretion, the receipt and the authorization 
required for point-of-purchase entries may be provided to 
the consumer on the same document or on different 
documents. 

5. FORMATTING REQUIREMENTS 

Individual Name 

Originators should be aware that, with the POP SEC 
Code, the inclusion of information in the Individual 
Name Field is optional. If the Originator chooses to 
utilize this field, it must include either ( 1) the 
Receiver's (consumer's) name, or (2) a reference 
number, identification number, or code that the 
merchant uses to identify a particular transaction or 
customer. (Note: When a reference number, 
identification number, or code is used to identify the 
transaction or customer, it should be uniquely related 
to the individual or transaction; A generic description 
is not an acceptable means to identify the Receiver or 
transaction.) 

Check Serial Number 

The rules governing POP entries require that the 
Originator ensure that the check serial number from 
the Receiver's source document is placed within the 
Check Serial Number Field of the POP entry. 
Originators should understand that the NACHA 
Operating Rules permit Originators to place only the 
check serial number within the Check Serial Number 
Field of the POP Entry Detail Record. The word 
"check," abbreviations such as "ck" or "chk," or 
other merchant codes must not be included within the 
field. Because the Check Serial Number Field is 
defined as an alphanumeric one, the NACHA 
Operating Rules require information within this field 
to be left justified and space filled. The serial 
number of the check must begin in the leftmost 
position of the Check Serial Number field, and any 
unused spaces within the field must be left blank. 



INCORRECT 



0001234 

000000000001234 
CK# 001234 
CK1234 

12346532986002 
CK1234 48832817 
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CORRECT 



1234 



Originators should be aware that the NACHA 
Operating Rules require RDFIs to print the check 
serial number on the consumer's bank statement. 



° Terminal City/Terminal State 

To ensure compliance with both the NACHA 
Operating Rules and Regulation E, which require the 
inclusion of terminal location information on the 
consumer's monthly bank account statement for POP 
entries, Originators must ensure that they have 
included a four-character name or abbreviation of the 
city in which the electronic terminal is located within 
the Terminal City Field, and a two-character 
abbreviation for the state in which the electronic 
terminal is located within the Terminal State Field of 
the POP Entry Detail Record. This information is 
used to identify the location of the electronic terminal 
used to originate the POP entry. 

6. RETURN OF POINT-OF-PURCHASE ENTRIES 

Originators should be aware that POP entries, like other 
ACH transactions, may be returned for a variety of 
reasons. Originators should be aware, however, that 
RDFIs can not return POP entries based on a consumer's 
claim that his authorization had been revoked (R07) since 
these are one-time transactions where the Originator will 
generally process the transactions immediately after the 
purchase is complete. As appropriate, however, the 
consumer may (1) request his RDFI to stop the payment 
of a POP entry (Return Reason Code R08), (2) request his 
RDFI to return an unauthorized/improper POP entry 
(Return Reason Code RIO), or (3) go directly to the 
Originator (merchant) to request a refund of the 
transaction. 

Originators should also be aware that, because the POP 
entry application does not require the Originator to 
capture the consumer's name for inclusion on the point- 
of-purchase entry, the RDFI must rely on the ODFI's 
warranty regarding the validity of the consumer's account 
number for posting purposes. The RDFI, therefore, may 
not return a point-of-purchase entry using Return Reason 
Codes R03 or Rl 7 solely because the consumer's name is 
not included in the Individual Name Field of the entry. 
The RDFI may, however, use these Return Reason Codes 
if otherwise appropriate. 

Originators must be prepared to handle returned point-of- 
purchase entries and must establish procedures that enable 
them to identify and contact the Receiver relating to any 
unpaid debit entry. Because the Originator does not retain 
the consumer's voided check as a source document, and 
because the consumer's name and address are not 
included as part of the MICR-capture process, Originators 
will need to develop alternative methods for retaining 
information necessary to identify the consumer for whom 



a point-of-purchase debit has been returned. The NA CHA 
Operating Rules limit the number of times an entry 
returned due to insufficient or uncollected funds may be 
reinitiated to no more than two times following the return 
of the original entry. Originators should establish 
procedures to ensure that returned POP entries are not 
reinitiated in excess of the limits prescribed by the 
NACHA Operating Rules. 

D. RESPONSIBILITIES OF ODFIs 

1. WARRANTIES AND LIABILITIES 

In addition to all other general ODFI warranties contained 
within the NACHA Operating Rules y each ODFI that 
chooses to transmit POP entries on behalf of its Originator 
also warrants to each RDFI, ACH Operator, and ACH 
Association that: 

the source document provided to the Originator for 
use in obtaining the Receiver's routing number, 
account number, and check serial number for the 
initiation of the POP entry 

- is returned voided to the Receiver after use by 
the Originator, and 

- has not been provided by the Receiver for use in 
any prior POP entry. 

ODFIs should consider modifications to their agreements 
with their Originators to address the origination of POP 
entries on behalf of their Originators. These 
modifications should address the extent to which the 
Originator and ODFI would share liability for POP 
transactions and should define any specific processing 
obligations relating to such transactions. 

2. FORMATTING REQUIREMENTS 

ODFIs must ensure that, prior to transmission to the ACH 
Operator, POP entries comply with all technical 
specifications and formatting requirements in accordance 
with the NACHA Operating Rules. ODFIs must ensure 
that: 

. • ■ ■ the check serial number from the Receiver's source 
document is placed within the Check Serial Number 
Field of the POP entry. 

ODFIs should understand that the NA CHA Operating 
Rules permit Originators to place only the check 
serial number within the Check Serial Number Field 
of the POP Entry Detail Record. The word "check," 
abbreviations such as "ck" or "chk," or other 
merchant codes must not be included within the field. 
Because the Check Serial Number Field is defined as 
an alphanumeric one, the NACHA Operating Rules 
require information within this field to be left 
justified and space filled. The serial number of the 
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check must begin in the leftmost position of the 
Check Serial Number field, and any unused spaces 
within the field must be left blank. 



INCORRECT 



CORRECT 



0001234 

000000000001234 
:CK#601234 
CK1234 

1234 6532986002 
CK1234 48832817 

1234 




ODFIs should be aware ihatihe NACHA Operating 
Rules require RDFIs to print the check serial number 
on the consumer's bank statement. 

they are aware that use of the Individual Name Field 
by the Originator is optional When used, it must 
contain either (1) the Receiver's name, or (2) a 
reference number, identification number, or code that 
the merchant uses to identify a particular transaction 
or customer. (Note: When a reference number, 
identification number, or code is used to identify the 
transaction or customer, it should be uniquely related 
to the individual or transaction. A generic 
description is not an acceptable means to identify the 
Receiver or transaction.) 

3. RETURN OF POINT-OF-PURCHASE ENTRIES 

ODFIs should be aware that POP entries, like other ACH 
transactions, may be returned for a variety of reasons in 
accordance with the return time frames prescribed by the 
NA CHA Operating Rules. ODFIs should be aware, 
however, that RDFIs can not return POP entries based on 
a consumer's claim that his authorization had been 
revoked (R07) since these are single entry transactions 
where the Originator will generally process the 
transactions immediately after the purchase is complete. 
As appropriate, however, the consumer may (1) request 
his RDFI to stop the payment of a POP entry (Return 
Reason Code R08), (2) request his RDFI to return an 
unauthorized/improper POP entry (Return Reason Code 
R10, R37), or (3) go directly to the Originator (merchant) 
to request a refund of the transaction. 

ODFIs should also be aware that, because the Point of 
Purchase application does not require the Originator to 
capture the consumer's name for inclusion on the POP 
entry, the RDFI must rely on the QDFI's warranty 
regarding the validity of the consumer's account number 
for posting purposes. The RDFI, therefore, may not 
return a point-of-purchase entry using Return Reason 
Codes R03 or Rl 7 solely because the consumer's name is 
not included in the Individual Name Field of the entry. 
The RDFI may, however, use these Return Reason Codes 
if otherwise appropriate. 



ODFIs should ensure that their Originators are prepared 
to handle returned POP entries and have established 
procedures that enable them to identify and contact the 
Receiver relating to any unpaid debit entry. Because the 
Originator does not retain the consumer's voided check as 
a source document, and because the consumer ' s name and 
address are not included as part of the MICR-capture 
process, ODFIs should ensure that their Originators 
understand the need to develop alternative methods for 
retaining information necessary to identify the consumer 
for whom a point-of-purchase debit entry has been 
returned. ODFIs must ensure that their Originators have 
established policies and practices to ensure that POP 
entries that are returned because of insufficient or 
uncollected funds are not reinitiated more than two times 
following the return of the original entry. 

4, STOP PAYMENTS ON POINT-OF-PURCHASE 

ENTRIES 

ODFIs should be aware that, in general, the NACHA 
Operating Rules regarding ACH stop payments require 
consumers to place a stop payment order on a debit at 
least three banking days prior to the scheduled date of the 
entry. Because the merchant will generally process POP 
transactions quickly, consumers are unlikely to be able to 
meetthe three-day advance notice requirement for placing 
a stop payment order on such entries. To ensure that a 
consumer has the ability to place a stop payment order on 
a POP entry, the NACHA Operating Rules ; require a 
consumer to provide a stop payment order to his financial 
institution in such a time and manner that allows the RDFI 
a reasonable opportunity to act on the stop payment order 
prior to acting on the debit entry. 

E. RESPONSIBILITIES OF RDFIs 

i; RETURN OF POINT-OF-PURCHASE ENTRIES 

POP entries may be returned for a variety of reasons in 
accordance with the requirements of the NACHA 
Operating Rules. With the exception of entries for which 
the consumer claims there was no authorization, the 
source document used for the POP entry is improper , and 
the source document to which the POP entry relates has 
also been presented for payment, the RDFI must transmit 
POP entry returns by its ACH Operator's deposit deadline 
for the return entry to be made available to the ODFI no 
later than the opening of business on the second banking 
day following the settlement date of the original entry. 
For an entry that the consumer claims is 
unauthorized/improper (R10) or (R37), the RDFI must 
transmit the return by its ACH Operator's deposit 
deadline for the return to be made available to the ODFI 
no later than the opening of business on the banking day 
following the sixtieth calendar day following the 
settlement date of the original entry. For the return of 
unauthorized entries, the RDFI must obtain a written 
statement under penalty of perjury from the consumer 
stating that the entry was not authorized. (Note: For 
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additional information on written statements under penalty 
of perjury, refer to the RDFIs chapter within Section II of 
these Guidelines.) 

RDFIs must be aware that, under certain circumstances, 
specific Return Reason Codes may not be used with POP 
entries: 

•■.■;■■■ Return Reason Code R03 (No Account/Unable to 
Locate Account) and Return Reason Code R17 
{File Record Edit Criteria) 

RDFIs must be aware that, for transactions initiated 
at the point-of-purchase, it is difficult for the 
Originator to capture the Receiver ' s. name in an 
automated fashion. For this reason, the Originator is 
not required to include the individual's name in the 
POP entry, and the RDFI must rely on the ODFI's 
warranty regarding the validity of the consumer's 
account number for posting purposes. 

The RDFI can not return POP entries solely because 
they lack an Individual Name. In general, typical 
Return Reason Codes used to return entries for which 
there is no Individual Name (e.g., R03, Rl 7) may not 
be used by the RDFI to return POP entries under 
these circumstances. These Return Reason Codes 
may, however, be used with POP entries for other 
valid reasons. 

• Return Reason Code R07 (Authorization Revoked 
by Customer) 

If appropriate, the consumer may (1) request his 
RDFI to stop the payment of a POP entry (Return 
Reason Code R08); (2) request his RDFI to return an 
unauthorized/improper point-of-purchase entry using 
Return Reason Code RIO or R37 (Reminder: the 
RDFI must obtain a written statement under penalty 
of perjury when using these Return Reason Codes); 
or (3) go directly to the Originator (merchant or 
biller) to request a refund for the transaction. 

RDFIs must be aware that they are prohibited from 
returning POP entries using Return Reason Code R07 
(Authorization Revoked by Customer) based on a 
consumer's claim that his authorization had been 
revoked since these are single entry payments where 
the Originator will generally process the transactions 
immediately after the purchase is complete. 

2. STOP PAYMENTS ON POINT-OF-PURCHASE 

In general, the NACHA Operating Rules regarding ACH 
stop payments require consumers to place a stop payment 
order on a debit at least three banking days prior to the 
scheduled date of the entry. Because the merchant will 
generally process POP transactions quickly, consumers 
are unlikely to be able to meet the three-day advance 



notice requirement for placing a stop payment order on 
such entries. To ensure that a consumer has the ability to 
place a stop payment order on a POP entry, the NACHA 
Operating Rules require a consumer to provide a stop 
payment order to his financial institution in such a time 
and manner that allows the RDFI a reasonable opportunity 
to act on the stop payment order prior to acting on the 
debit entry. 

3. STATEMENT REQUIREMENTS 

RDFIs are required to provide the Check Serial Number 
of the consumer's source document on the consumer's 
monthly bank account statement for all POP entries/The 
RDFI must also provide on the statement the Terminal 
City and the Terminal State in which the POP entry was 
originated. RDFIs need to ensure that this information is 
provided on the consumer's statement. 

Note: The Federal Reserve Board's Official Staff 
Commentary on Regulation E requires the inclusion of 
terminal location information on the consumer's monthly 
bank account statement. When a POS terminal is used to 
capture data electronically to initiate an EFT, the 
Regulation E Official Staff Commentary considers the 
POS terminal to be an electronic terminal, even if no 
access device is used, such as when a check is used to 
capture information to initiate a one-time EFT. As a 
result, when a check is used as a source document at the 
point of purchase and run through a terminal to read the 
MICR information, as is the case with POP entries, it is 
necessary to ensure compliance with Regulation E's 
requirements for electronic terminals, which mandate the 
inclusion of the terminal location on the monthly bank 
statement. 



SECTION IV 
SPECIAL TOPICS - 

CHAPTER XIII 
ACCOUNTS RECEIVABLE 

ENTmEs- ; : : 

A. INTRODUCTION 

Accounts Receivable Entries (ARC) are Single-Entry 
debits used by Originators for the conversion of a 
consumer check received via the U. S . mail or at a dropbox 
location for the payment of goods or services. This 
application enhances the efficiency of the ACH Network 
by expanding the scope of consumer electronic check 
activity. 
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This chapter addresses issues relating to the origination 
and receipt of ARC entries. 

B. LEGAL FRAMEWORK 

ARC entries are subject to the requirements of the 
NA CHA Operating Rules, the Electronic Fund Transfer 
Act, and the Federal Reserve Board's Regulation E. The 
ARC entry is a single entry debit to a consumer's account, 
initiated by an Originator for purchases or payments that 
are made by mailing a check (used as a source document) 
to the Originator via the U.S. mail or by placing the check 
in a dropbox. The Originator is required to use a reading 
device to capture the MICR line (routing number, account 
number, and check serial number) of the source document 
(check) but may key enter the amount of the transaction. 
This application requires the Originator to provide, prior 
to the receipt of each check, notice to the consumer that 
receipt of his check will be authorization for the check to 
be used as a source document for an ACH debit 
transaction to the Receiver's account at his financial 
institution. Used only as a source document, the check 
will not enter into the check collection process, nor will it 
constitute an access device as defined by Regulation E. 

C. ELIGIBLE ITEMS 

The Originator can accept a check as a source document 
to initiate an ARC entry only if it has been sent through 
the U.S. mail or delivered to a dropbox. To be used as a 
source document for this type of transaction, the check or 
sharedraft must: (1) contain a pre-printed serial number, 
(2) be drawn on a consumer account, and (3) be 
completed and signed by the consumer. 

Checks that may not be used as source documents for 
ARC entries include: 

•'■ corporate checks, 

• third-party checks, 

•'■'.. demand (hafts and third-party drafts that do not 

contain the signature of the Receiver, 
° credit card checks, - 

* obligations of a financial institution (e.g. cashier's 
checks, money orders, etc.), 

.•■■'. checks drawn on the Treasury of the United States, 
a Federal Reserve Bank, or a Federal Home Loan 
Bank, 
. • ■ ■ ■ checks drawn on a state or local government, or 
■•■.■■ checks payable in a medium other than United 
States currency. 

D. OBLIGATIONS OF ORIGINATORS 

1. AGREEMENTS WITH ODFIs 

Originators choosing to utilize the ACH Network to 
convert consumer checks received through the U.S. mail 
or at a dropbox location for payment of goods or services 
and collect them using Accounts Receivable Entries 



should consider modifications to their agreements with 
their ODFIs to address the origination of ARC entries. 
Originators should ensure that their ODFI/Originator 
agreements not only bind the Originator to the 
requirements of the NA CHA Operating Rules, but they 
should also address any processing obligations, timing, 
liabilities, etc., that are unique to the ARC application. 
These modifications could, for example, address the 
extent to which the Originator and ODFI would share 
liability for the following warranties as they apply to the 
origination of ARC entries: 

■> the amount of the entry, the routing number, the 
account number, and the check serial number are in 
accordance with the source document; 

V the Originator must retain a reproducible, legible, 
image, microfilm, or copy of the front of the 
Receiver's source document for two years from the 
Settlement Date of the ARC entry. While no longer 
required by the NACHA Operating Rules, Originators 
may also choose, at their discretion, to retain a copy 
of the back of the Receiver's source document. An 
RDFI that receives an ARC entry may send the ODFI 
a written request for a copy of the source document 
to which the ARC entry relates. The RDFI 's written 
request must be received by the ODFI within two 
years of the Settlement Date of the ARC entry. Upon 
receipt of the written request, the ODFI warrants to 
the RDFI that it will send a copy of the front of the 
Receiver's source document within ten banking days. 
The copy must indicate that it is a copy on its face. 

» The source document to which the ARC entry relates 
will not be presented or returned such that any person 
will be required to make payment based on the source 
document. In addition to the RDFI, ACH Operator, 
and Association, this warranty runs to any other party 
that may be liable on the source document. 

• The source document to which the ARC entry relates 
must be destroyed within fourteen days of the 
Settlement Date of the entry. 

For more information on agreements, refer to the ODFIs 
chapter within Section II of these Guidelines. 

2. AUTHORIZATION/NOTIFICATION 
REQUIREMENTS 

Originators are required to provide notice to the Receiver, 
prior to the receipt of each source document that will be 
used as the basis for the origination of an ARC entry, that 
receipt of the Receiver's check will be deemed to be the 
Receiver's authorization for an ACH debit entry to the 
Receiver's account, in accordance with the terms of the 
source document. The check will be used solely as a 
source document for capturing the Receiver's routing 
number, account number, check serial number, and dollar 
amount of the entry. The provision of the notice by the 
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Originator to the consumer and the receipt of the source 
document together constitute authorization of the ARC 
entry. 

Originators of ARC entries are required to allow 
Receivers to opt out of ARC check conversion. 
Originators must establish reasonable procedures under 
which Receivers may notify Originators that their checks 
are not to be converted to ARC entries. The Rules do not 
prescribe specific procedures that an Originator must 
employ to allow a Receiver to opt out; rather, Originators 
may establish their own reasonable policies and practices 
for enabling a Receiver to opt out of check conversion for 
a specific checking account. Originators must be aware 
that a Receiver's request to opt out of any ARC activity 
involving a particular checking account must remain in 
effect unless or until the Receiver notifies the Originator 
otherwise; Originators may not require a Receiver to opt 
out for each check drawn on that account and will need to 
ensure that they establish procedures to apply such opt out 
requests to all checks involving that Receiver's particular 
checking account. 

This rule change does not require Originators to provide 
notice to Receivers concerning their opt out rights with 
respect to ARC entries; however, in the spirit of good 
customer service and to foster the acceptance of check 
conversion activity, Originators are strongly encouraged 
to notify Receivers of their right to opt out and to provide 
the Receiver with a telephone number for any inquiries 
with respect to the ARC application in addition to a notice 
explaining the consumer's ability to opt out. 

3: COLLECTION FEES 

ARC entries must be originated so that the amount of the 
entry, the routing number, the account number, and the 
check serial number accurately reflect the source 
document. No fees may be added to the amount of the 
source document when it is transmitted as an ARC entry. 
An Originator desiring to use the ACH Network to collect 
a service fee must originate a separate PPD, TEL, or 
WEB debit entry to the consumer's account and must 
follow all rules governing the specific transaction used, 
including having First obtained the consumer's 
authorization for such an entry in the manner specified by 
the NACHA Operating Rules. 

4. FORMATTING REQUIREMENTS 

Company Name 

Originators must ensure that the original payee on the 
face of the source document appears within the 
Company Name Field of the Company/Batch Header 
Record of the ARC entry. (Note: Minor variations in 
how the payee's name appears in this field are 
acceptable). 



Check Serial Number 

Originators must ensure that the check serial number 
of the source document to which the ARC entry 
relates is placed within the Check Serial Number 
Field of the ARC Entry Detail Record. 

The NACHA Operating Rules permit Originators to 
place only the check serial number within the Check 
Serial Number Field of the ARC Entry Detail Record. 
The word "check," abbreviations such as "ck" or 
"chk," or other merchant codes must not be included 
within the field. Because the Check Serial Number 
Field is defined as an alphanumeric one, the NACHA 
Operating Rules require information within this field 
to be left justified and space filled. The serial 
number of the check must begin in the leftmost 
position of the Check Serial Number field, and any 
unused spaces within the field must be left blank. 



INCORRECT 



CORRECT 



0001234 

000000000001234 

CK#001234 

CK1234 

1234 6532986002 

CK1234 48832817 

1234 




Originators should be aware that the NA CHA 
Operating Rules require RDFIs to print the check 
serial number on the consumer's bank statement. 

Individual Name 

The inclusion of the consumer's name within the 
Individual Name Field of the ARC Entry Detail 
Record is optional at the discretion of the Originator. 
If the Originator chooses to utilize this field, it must 
include either (1) the Receiver's (consumer's name), 
or (2) a reference number, identification number, or 
code that the merchant uses to identify a particular 
transaction or customer. (NOTE: When a reference 
number, identification number, or code is used to 
identify the transaction or customer, it should be 
uniquely related to the individual or transaction. A 
generic description is not an acceptable means to 
identify the Receiver or the transaction.) 



5. REINITIATION OF ARC ENTRIES 

Originators must be aware that the NACHA Operating 
Rules restrict the number of times that any entry, 
including ARC entries, returned for insufficient or 
uncollected funds may be reinitiated to no more than two 
times following the return of the original entry. An 
Originator must remedy the reason for the return of an 
ARC entry returned for any other reason before 
reinitiating the transaction. Originators must ensure that 
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they have established policies and procedures to comply 
with these rules governing reinitiation of ARC entries. 

6. RETENTION OF SOURCE DOCUMENT 

Each Originator of ARC entries must retain an image, 
microfilm, or other copy of the front of the consumer's 
source document for a period of two years from the 
Settlement Date of the entry. While no longer required by 
the NACHA Operating Rules, Originators may also 
choose, at their discretion, to retain a copy of the back of 
the Receiver's source document. The ODFI must send a 
copy of the front of the source document to the RDFI 
within 10 banking days of receipt of a written request by 
the RDFI within two years of the Settlement Date of the 
entry. 

The original source document to which the ARC entry 
relates must be destroyed by the Originator within 
fourteen days of the Settlement Date of the entry. This 
requirement is to protect against the risk that, by error, the 
source document might subsequently be entered into the 
check processing system for payment as a check. 

7. RETURN OF ACCOUNTS RECEIVABLE 

ENTRIES.;..;... ... 

Most ARC entries will need to be returned by the RDFI so 
that the return entry is made available to the ODFI no later 
than the opening of business on the second banking day 
following the Settlement Date of the ARC entry. 



ARC entries may also be returned by the RDFI for 60 
days from the Settlement Date for the following reasons: 
1) improper source document (i.e., the source document 
is something other than a check drawn on a consumer 
account), 2) no notice was provided to the consumer that 
his check was going to be converted to an ACH debit, 3) 
the source document was presented for payment as a 
check through the check collection system, or 4) the ARC 
transaction was initiated in an amount other than that 
indicated on the source document. In these four 
circumstances, the RDFI would require the consumer to 
sign or similarly authenticate a written statement under 
penalty of perjury prior to being re-credited for the 
transaction. 

ARC entries can also be returned by the RDFI for 60 days 
from the settlement date if the consumer places a stop 
payment on the source document (i.e., in the check stop 
payment system) instead of the ACH stop payment 
system. This sixty-day time frame will allow a "safety 
net" for RDFIs that have opted not to build a bridge 
between their check and ACH systems to check for stop 
payment orders for this application. A written statement 
under penalty of perjury is not required for this return 
reason. 



8. STOP PAYMENTS 

As with other Single-Entry ACH transactions, including 
POP and RCK, consumers desiring to place stop payment 
orders on ARC entries will be required to place the stop 
payment order to the RDFI in such a time and manner that 
allows the RDFI a reasonable opportunity to act on the 
stop payment order prior to acting on the debit entry. 

E. RESPONSIBILITIES OF ODFIs 



1. WARRANTIES AND LIABILITIES 

In addition to all other ODFI warranties contained within 
the NACHA Operating Rules, each ODFI that chooses to 
transmit ARC entries on behalf of its Originators also 
warrants to each RDFI, ACH Operator, and ACH 
Association that: 

the amount of the entry, the routing number, the 
account number, and the check serial number are in 
accordance with the source document; 



the Originator must retain a reproducible, legible, 
image, microfilm, or copy of the front of the 
Receiver's source document for two years from the 
Settlement Date of the ARC entry. While no longer 
required by the NACHA Operating Rules, Originators 
may also choose, at their discretion, to retain a copy 
of the back of the Receiver's source document. An 
RDFI that receives an ARC entry may send the ODFI 
a written request for a copy of the source document 
to which the ARC entry relates. The RDFI' s written 
request must be received by the ODFI within two 
years of the Settlement Date of the ARC entry. Upon 
receipt of the written request, the ODFI warrants to 
the RDFI that it will send a copy of the front of the 
Receiver's source document within ten banking days. 
The copy must indicate that it is a copy on its face. 



• The source document to which the ARC entry relates 
will not be presented or returned such that any person 
will be required to make payment based on the source 
document. In addition to the RDFI, ACH Operator, 
and Association, this warranty runs to any other party 
that may be liable on the source document. 

The original source document to which the ARC 
entry relates must be destroyed within fourteen days 
of the Settlement Date of the entry. 

ODFIs should consider modifications to their agreements 
with their Originators that choose to utilize the ACH 
Network to collect truncated checks via ACH debits. 
These modifications should address issues such as 
whether the Originator is willing to accept some of the 
liability for the ODFFs warranties, as listed above, 
relating to the origination of these transactions on the 
Originator's behalf. 
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2 FORMATTING REQUIREMENTS 



Company Name 

Originators must ensure that the original payee on the 
face of the source document appears within the 
Company Name Field of the Company/Batch Header 
Record of the ARC entry. (Note: Minor variations in 
how the payee's name appears in this field are 
acceptable). 

Check Serial Number 

ODFIs are responsible for the proper formatting of 
each ARC entry and should ensure that their 
Originators place the check serial number of the 
source document to which the ARC entry relates 
within the Check Serial Number Field of the ARC 
Entry Detail Record. 

ODFIs should understand that the NACHA Operating 
Rules permit Originators to place only the check 
serial number within the Check Serial Number Field 
of the ARC Entry Detail Record. The word "check," 
abbreviations such as "ck" or "chk," or other 
merchant codes must not be included within the field. 
Because the Check Serial Number Field is defined as 
an alphanumeric one, the NACHA Operating Rules 
require information within this field to be left 
justified and space filled. The serial number of the 
check must begin in the leftmost position of the 
Check Serial Number Field, and any unused spaces 
within the field must be left blank. 



INCORRECT 



CORRECT 



0001234 

000000000001234 

CK# 001234 

CK1234 

1234 6532986002 

CK1234 488328 17 

1234 



ODFIs should be aware that the NA CHA Operating 
Rules require RDFIs to print the check serial number 
on the consumer's bank statement. 

Individual Name 

The inclusion of the consumer's name within the 
Individual Name Field of the ARC Entry Detail 
Record is optional at the discretion of the Originator. 
If the Originator chooses to utilize this field, it must 
include either (1) the Receiver's (consumer's name), 
or (2) a reference number, identification number ^ or 
code that the merchant uses to identify a particular 
transaction or customer. (NOTE: When a reference 
number, identification number, or code is used to 
identify the transaction or customer, it should be 
uniquely related to the individual or transaction. A 



generic description is not an acceptable means to 
identify the Receiver or the transaction,) 

3. RETURN OF ACCOUNTS RECEIVABLE 
ENTRIES 

Most ARC entries will need to be returned by the RDFI so 
that the return entry is made available to the ODFI no later 
than the opening of business on the second banking day 
following the Settlement Date of the ARC entry. 

ARC entries may also be returned by the RDFI for 60 
days from the Settlement Date for the following reasons: 
1) improper source document (i.e., the source document 
is something other than a check drawn on a consumer 
account), 2) no notice was provided to the consumer that 
his check was going to be converted to an ACH debit, 3) 
the source document was presented for payment as a 
check through the check collection system, or 4) the ARC 
transaction was initiated in an amount other than that 
indicated on the source document. In these four 
circumstances, the RDFI will require the consumer to sign 
or similarly authenticate a written statement under penalty 
of perjury prior to being re-credited for the transaction. 

ARC entries can also be returned by the RDFI for 60 days 
from the settlement date if the consumer places a stop 
payment on the source document (i.e., in the check stop 
payment system) instead of the ACH stop payment 
system. This sixty-day time frame will allow a "safety 
net" for RDFIs that have opted not to build a bridge 
between their check and ACH systems to check for stop 
payment orders for this application. A written statement 
under penalty of perjury is not required for this return 
reason. 

The NA CHA Operating Rules do not require the 
Originator to include the Receiver's (consumer's ) name 
within the Individual Name Field of the ARC Entry Detail 
Record. As a result, the RDFI will need to rely on the 
ODFI's warranty regarding the validity of the consumer's 
account number for posting purposes. The RDFI may not 
return an ARC entry using Return Reason Codes R03 or 
R17 solely because the consumer's name is not included 
in the Individual Name Field of the entry. The RDFI may, 
however, used these Return Reason Codes if otherwise 
appropriate. 

4. STOP PAYMENTS 

As with other Single-Entry ACH transactions, including 
POP and RCK, consumers desiring to place stop payment 
orders on ARC entries will be required to place the stop 
payment order to the RDFI in such a time and manner that 
allows the RDFI a reasonable opportunity to act on the 
stop payment order prior to acting on the debit entry. 
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5. RETENTION OF SOURCE BOGUMENT 

ODFIs should be aware that each Originator of ARC 
entries must retain an image, microfilm, or other copy of 
the front of the consumer's source document for a period 
of two years from the Settlement Date of the entry. While 
no longer required by the NACHA Operating Rules, 
Originators may also choose, at their discretion, to retain 
a copy of the back of the Receiver's source document. 
The ODFI must send a copy of the front of the source 
document to me RDFI within 1 banking days of receipt 
of a written request by the RDFI within two years of the 
Settlement Date of the entry. 

ODFIs must also be aware that the source document to 
which the ARC entry relates must be destroyed by the 
Originator within fourteen days of the Settlement Date of 
the entry. This requirement is to protect against the risk 
that, by error, the source document might subsequently be 
entered into the check processing system for payment as 
a check. 

F. RESPONSIBILITIES OF RDFIs 



Return Reason Code R03 (No Accoun t/Un a ble to 
Locate Account) and Return Reason Code R17 
(File Record Edit Criteria) 

RDFIs must be aware that, with ARC entries, where 
a MICR reader must be used to obtain the Receiver's 
routing and account numbers, it is difficult for an 
Originator to capture the Receiver's name in ari 
automated fashion. For this reason, Originators are 
not required to include the Receiver's (consumer's) 
name in the Individual Name Field of the ARC Entry 
Detail Record. The RDFI must rely on the ODFI' s 
warranty regarding the validity of the consumer's 
account number for posting purposes. 

An RDFI may not return ARC entries solely because 
they lack an Individual Name. In general, typical 
Return Reason Codes used to return entries for which 
there is no Individual Name (e.g., R03, R17) may not 
be used by the RDFI to return ARC entries under 
these circumstances. These Return Reason Codes 
may, however, be used with ARC entries for other 
valid reasons. 



1. RETURN OF ACCOUNTS RECEIVABLE 

. entries 

Most ARC entries will need to be returned by the RDFI so 
that the return entry is made available to the ODFI no later 
than the opening of business on the second banking day 
following the Settlement Date of the ARC entry. 



ARC entries may also be returned by the RDFI for 60 
days from the Settlement Date for the following reasons: 
1) improper source document (i.e., the source document 
is something other than a check drawn on a consumer 
account), 2) no notice was provided to the consumer that 
his check was going to be converted to an ACH debit, 3) 
the source document was presented for payment as a 
check through the check collection system, or 4) the ARC 
transaction was initiated in an amount other than that 
indicated on the source document. In these four 
circumstances, the RDFI will require the consumer to sign 
or similarly authenticate a written statement under penalty 
of perjury prior to being re-credited for the transaction. 

ARC entries can also be returned by the RDFI for 60 days 
from the settlement date if the consumer places a stop 
payment on the source document (i.e., in the check stop 
payment system) instead of the ACH stop payment 
system. This sixty-day time frame will allow a "safety 
net" for RDFIs that have opted not to build a bridge 
between their check and ACH systems to check for stop 
payment orders for this application. A written statement 
under penalty of perjury is not required for this return 
reason. 

RDFIs must be aware that the following Return Reason 
Codes may not be used with ARC entries solely because 
the entry lacks an Individual Name: 



2. STOP PAYMENTS 

As with other Single-Entry ACH transactions, including 
POP and RCK, consumers desiring to place stop payment 
orders on ARC entries will be required to provide the stop 
payment order to the RDFI in such a time and manner that 
allows the RDFI a reasonable opportunity to act on the 
stop payment order prior to acting on the debit entry. An 
RDFI returning an ARC entry due to stop payment must 
do so in such a time and manner that enables the return to 
be made available to the ODFI no later than the opening 
of business on the second banking day following the 
settlement date of the ARC entry. 

It is possible that consumers may, in error, instruct their 
RDFIs to place a stop payment order on the source 
document (the check) used for the ARC entry rather than 
on the ACH debit entry itself. RDFIs should consider 
establishing a system link to check for potential stop 
payment orders in their DDA system when an ARC entry 
is received, To accommodate situations in which the 
RDFI's checking and ACH systems are not linked, the 
NACHA Operating Rules allow an RDFI sixty days from 
the settlement date of the entry to return an ARC entry 
when the stop payment order was placed on the source 
document. Return Reason Code, R38 (Stop Payment on 
Source Document) is to be used for this purpose. 



3. COPY OF SOURCE DOCUMENT 



RDFIs must be aware that the source document to which 
the ARC entry relates must be destroyed by the Originator 
within fourteen days of the Settlement Date of the entry. 
This requirement is to protect against the risk that, by 
error, the source document might subsequently be entered 
into the check processing system for payment as a check. 
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RDFIs should understand, however, that each Originator 
of ARC entries must retain an irmge, microfilm, or other 
copy of the front of the consumer's source document for 
a period of two years from the Settlement Date of the 
entry. While no longer required by the NACHA Operating 
Rules, some Originators may also choose, at their 
discretion, to retain a copy of the back of the Receiver's 
source document. The ODFI is required to send a copy of 
the front of the source document to the RDFI within 10 
banking days of receipt of a written request by the RDFI 
within two years of the Settlement Date of the entry. 



4. STATEMENT REQUIREMENTS 



In addition to all other requirements of Appendix Four 
(Minimum Description Standards) of the NACHA 
Operating Rules, RDFIs should be aware that they are 
required to provide the check serial number from each 
ARC entry on the consumer's monthly bank account 
statement. 



SECTION IV 
SPECIAL TOPICS 

CHAPTER XIV 

INTERNET-INITIATED ENTRIES 

A. INTRODUCTION 

Internet-Initiated Entries (WEB entries) are used for the 
origination of debit entries (either recurring or Single 
Entry) to a consumer's account pursuant to an 
authorization that is obtained from the Receiver via the 
Internet. This SEC Code helps to address unique risk 
issues inherent to the Internet payment environment 
through requirements for added security procedures and 
obligations. 



B. BACKGROUND 

There are three unique characteristics of the Internet that 
warranted the development of NACHA Operating Rules: 
1) the anonymity of the Internet creates an environment in 
which parties are not certain with whom they are doing 
business, which poses unique opportunities for fraud, 2) 
the Internet is an open network, which requires special 
security procedures to be deployed to prevent 
unauthorized access to consumer financial information, 
and 3) the sheer number and speed with which payments 
can be transacted over the Internet, known as volume and 
velocity. 

While it was imperative to incorporate specific security 
measures for Internet-initiated ACH debits into the 



NACHA Operating Rules, it was also important to refrain 
from prescribing a rigid set of rules that impose a one- 
size-fits-all solution in a rapidly-changing environment. 
Technical solutions and business practices to support 
these payments continue to evolve, and, therefore, the 
NACHA Operating Rules balance the need for security 
with the desire to maintain some flexibility regarding the 
methods ACH Network participants use to comply with 
the Rules. These Operating Guidelines recommend 
methods ACH participants can use to implement and 
comply with the NA CHA Operating Rules for WEB 
entries. (Note: In any case where these key components 
are not specifically required under the NA CHA Operating 
Rules, all are recommended by NACHA as sound 
business practices.) 

The current NACHA Operating Rules for WEB entries 
establish a set of critical requirements necessary to set a 
minimum amount of protection for WEB entries. Over the 
long term, additional enhancements to the Rules maybe 
necessary to build upon this foundation. 

C. LEGAL FRAMEWORK 

WEB entries are subject to the requirements of the 
NACHA Operating Rules, the Electronic Fund Transfer 
Act, and Regulation E, as promulgated by the Federal 
Reserve Board. 

D. DEFINITIONS 




i; WEB ENTRY 

A WEB entry is defined as a debit entry to a Consumer 
Account initiated by an Originator pursuant to an 
authorization that is obtained from the Receiver via the 
Internet. There are two components of the definition that 
are important to address: 

• the WEB Standard Entry Class (SEC) code is only 
appropriate to use when initiating debit entries that 
have been authorized by the Receiver via the Internet. 
An authorization that was obtained from the Receiver 
in person, through the mail or over the telephone in 
order to effect an Internet payment is not to be 
initiated as a WEB transaction. These transactions 
should use the appropriate SEC code as defined by 
the NACHA Operating Rules. For example, if a 
Receiver authorizes a monthly debit to his or her 
account for a bill payment service via paper in 
writing, but goes to the toiler's website to verify the 
amount of the bill each month, this transaction would 
constitute a PPD entry rather than a WEB entry; and 

the WEB SEC code cannot be used to initiate credit 
entries except for reversals of WEB debit entries. 
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2. COMMERCIALLY REASONABLE 

For all WEB entries, each Originator is obligated to 
ensure that certain aspects of a transaction have been 
handled in a commercially reasonable manner. In 
addition, each ODFI warrants that the Originator has 
handled those aspects of a transaction in a commercially 
reasonable manner. Those aspects of the transaction 
include commercially reasonable methods of 
authentication to verify the identity of the Receiver, 
fraudulent transaction detection systems, security 
technology to establish a secure Internet session, and 
procedures to verify the validity of the RDFI's routing 
number. 

A commercially reasonable system, technology, practice, 
or procedure is one that corresponds to commonly 
accepted commercial practices among commonly situated 
Originators conducting similar types of transactions. In 
other words, the concept of commercial reasonableness 
means that an Originator, given the facts of a specific 
transaction, acted in a way that other similar Originators 
would have acted. Whether an Originator has fulfilled its 
obligations to perform in a commercially reasonable 
manner will be determined based on an evaluation of the 
circumstances, including any or all of the following: 
transaction amount, volume of payments originated, type 
of goods or services sold, control of goods or funds, 
whether or not the parties had an existing business 
relationship, and, finally, a weighing of the cost to the 
Originator to employ a particular technology or procedure 
against the level of protection it affords to the Originator 
and other ACH participants. Accordingly, what constitutes 
a commercially reasonable system, technology, practice or 
procedure may change over time. For example, as new 
technology becomes available or costs of certain 
technologies or procedures decrease, new standards of 
commercial reasonableness may evolve. Therefore, 
Originators and ODFIs need to work together to ensure 
continued compliance. 



The person challenging the use of a particular system, 
technology, practice or procedure has the burden of 
establishing that the system, technology, practice or 
procedure employed by the Originator was not 
commercially reasonable. 



3. SINGLE-ENTRY v. RECURRING 

The WEB Standard Entry Class Code applies to both 
recurring and Single-Entry Internet-initiated payments. In 
the case of WEB entries, a Single-Entry payment means 
a one-time transfer of funds initiated by an Originator in 
accordance with the Receiver's authorization for a single 
ACH debit to the Receiver's account. One example of a 
Single-Entry WEB transaction would be a consumer 
purchase of a book online. 

For purposes of WEB entries, a recurring payment is: 1) 
an entry that has been set up to occur, based on the 



Receiver's authorization obtained via the Internet, at 
regular intervals without any additional intervention of the 
consumer (i.e., a monthly debit to the consumer's account 
for a mortgage payment); or 2) multiple entries, based on 
an authorization provided by the consumer establishing a 
relationship with the Originator for a specific type of 
activity, that are originated each time upon the specific 
instructions of the consumer (i.e., an instruction to a 
broker to purchase or sell securities). 

There are two primary reasons why a distinction has been 
made between recurring and Single-Entry WEB 
transactions. First, Single-Entry payments have the 
potential to be more risky because the Originator and 
Receiver may not have a prior relationship established, 
which makes robust authentication more difficult and the 
possibility of fraud and exception processing higher. For 
example, a one-time purchase of expensive stereo 
equipment is thought to be more susceptible to fraud than 
a recurring payment for a telephone bill. While all of this 
is subjective and depends highly on each unique 
transaction, it is important for both Originators and ODFIs 
to be able to recognize these payments in order to monitor 
them separately for risk management purposes if they so 
choose. 

Second, the rules relating to the revocation of 
authorization and stop payment requirements for WEB 
entries are different for Single-Entry and recurring 
payments. Originators are not required to include within 
the authorization language for a Single-Entry WEB entry 
the method by which the consumer can revoke his 
authorization for the transaction. (Note: This revocation 
language is required to be included in authorizations for 
all recurring payments, including recurring WEB entries.) 
This is because these are one-time payments and the 
Receiver will most likely not have the opportunity to 
revoke the authorization before the transaction is 
processed. Accordingly, RDFIs are prohibited from 
returning Single-Entry WEB entries based on a 
consumer's claim that his authorization has been revoked 
(i.e., using Return Reason Code R07). 

Likewise, to ensure that a consumer has the ability to 
place a stop payment order on a Single-Entry WEB entry, 
the NACHA Operating Rules allow a consumer to provide 
a stop payment order to his financial institution so long as 
it is given in such a time and manner that allows theRDFI 
a reasonable opportunity to act on the stop payment order 
prior to acting on the debit entry. In contrast, for a 
recurring payment, the consumer has the right to place a 
stop payment only as long as they request the stop 
payment at least three days prior to the scheduled 
settlement date of the entry. 



E. ACH DATA SECURITY REQUIREMENTS 

For all ACH transactions that involve the exchange or 
transmission of banking information (which includes, but 
is not limited to, an entry, entry data, a routing number, an 
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account number, and a PIN or other identification symbol) 
via an Unsecured Electronic Network, the NACHA 
Operating Rules require that such banking information be 
either ( 1 ) encrypted using a commercially reasonable 
security technology that, at a minimum, is equivalent to 
128-bitRC4 encryption technology, or (2) transmitted via 
a secure session that utilizes a commercially reasonable 
security technology that provides a level of security that, 
at a minimum, is equivalent to 128-bit RC4 encryption 
technology. 

These encryption requirements must be employed prior to 
the key-entry and through the transmission of any banking 
information exchanged over such an Unsecured Electronic 
Network between ( 1 ) an Originator and a Receiver; (2) an 
Originator and an ODFI; (3) an ODFI and an ACH 
Operator; (4) an ACH Operator and an RDFI; and (5) an 
Originator, ODFI, RDFI, or ACH Operator and a Third- 
Party Service Provider. Transmissions or exchanges of 
banking information using voice or keypad inputs from a 
wireline or wireless telephone are not subject to this data 
security requirement unless the telephone is used to access 
the Internet. An application in which the Originator 
obtains information from the Receiver by another means 
(such as the telephone) and then key enters the 
information via the Internet is, for example, subject to 
these data security requirements. However, information 
delivered via telephone line, such as a leased line, or 
dialed into a financial institution's modem pool is not 
subject to this requirement. 



Verification of Identity of Originators 

The NACHA Operating Rules also require ODFIs to 
utilize commercially reasonable methods to establish the 
identity of each Originator that uses an Unsecured 
Electronic Network, such as the Internet, to enter into a 
contractual relationship with the ODFI for the origination 
of ACH transactions. Such a requirement helps to ensure 
that ODFIs employ measures to know the Originators with 
whom they establish relationships over Unsecured 
Electronic Networks and to verify those Originators' 
identities. 

F. OBLIGATIONS OF ORIGINATORS 



1. AGREEMENTS WITH ODFIs 



Originators choosing to utilize the ACH Network for 
initiating WEB transactions should consider modifications 
to their agreements with their ODFIs to address the 
origination of these entries. These modifications should 
address the extent to which the Originator and ODFI will 
share liability for WEB transactions and should define any 
specific processing obligations relating to such 
transactions. For example, the NACHA Operating Rules 
require ODFIs to set specific exposure limits for WEB 
transactions for each Originator, and the agreements may 
need to be modified to address those limits. For more 



information on agreements, refer to the ODFIs chapter 
within Section II of these Guidelines. 

2. AUTHORIZATION REQUIREMENTS 

Originators of WEB entries must obtain the consumer's 
authorization prior to initiating a debit entry under this 
application. Although the NACHA Operating Rules do 
not prescribe specific authorization language for the WEB 
application, the authorization must conform to the 
requirements of the NACHA Operating Rules, which 
require that the authorization (1) be in a writing that is 
signed or similarly authenticated by the Receiver, (2) be 
readily identifiable as an ACH debit authorization, (3) 
clearly and conspicuously state its terms, and (4) must (for 
recurring payments only) provide the Receiver with a 
method to revoke their authorization by notifying the 
Originator in the manner prescribed. 

To meet the first requirement that the authorization be in 
writing, in the context of WEB entries, this means that the 
consumer must be able to read the authorization language 
displayed on a computer screen or other visual display. 
The Originator should prompt the consumer to print the 
authorization and retain a copy. The Originator must be 
able to provide the consumer with a hard copy of the 
authorization if requested to do so. Only the consumer 
may authorize the WEB transaction, and not a Third-Party 
Service Provider on behalf of the consumer. 

The NACHA Operating Rules include the use of a digital 
signature or code to similarly authenticate a written 
authorization. This does not exclude other methods of 
similarly authenticating an authorization, such as a shared 
secret, passwords, biometrics, etc. To satisfy the 
requirements of the NACHA Operating Rules, which 
parallel Regulation E, the authentication method chosen 
must not only identify the consumer but also must 
demonstrate the consumer's assent to the authorization. 

The Federal Reserve Board, in its Official Staff 
Commentary to Regulation E, has clarified that the 
similarly authenticated standard permits signed, written 
authorizations to be provided electronically, and that such 
writing and signature requirements are satisfied by 
compliance with the Electronic Signatures in Global and 
National Commerce Act (15 U.S.C. 7001 et seq.), which 
defines electronic records (as contracts or other records 
created, generated, sent, communicated, received, or 
stored by electronic means) and electronic signatures. 
Electronic signatures include, but are not limited to, 
digital signatures and security codes. 

3. RISK MANAGEMENT .- 

To help mitigate the added risk associated with Internet- 
based payments, Originators are obligated to comply with 
stringent risk management requirements when originating 
WEB entries. At a minimum, Originators of such entries 
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must implement the following risk management 
techniques: 

• Authentication 

The best way in which Originators can minimize the 
potential for fraudulent Internet-initiated ACH 
transactions is to employ robust authentication 
methods to verify the identity of the Receiver before 
accepting ACH debit authorizations online. The 
more robust the authentication; the less likely the 
transaction will be fraudulent and the less likely the 
payment will be returned to the Originator as 
unauthorized. Since the Originator may ultimately be 
responsible for unauthorized or fraudulent ACH 
transactions when those transactions are returned, it 
is to their benefit to incorporate adequate levels of 
authentication into their online ACH payment 
processes. 

When considering which authentication methods to 
deploy, Originators should determine whether their 
WEB entry transactions will be conducted with 
existing customers, new customers or both. 
Originators with an established business relationship 
with the consumer - whether established online, in 
person, over the telephone, or some other method - 
can usually authenticate those customers using shared 
secrets such as a PIN, password or previous 
transaction history. 

Conversely, there is no standard authentication 
process being used online to identify and authenticate 
unknown individuals on the Internet. The Originator 
still has the responsibility to choose an appropriate 
solution for authentication that will minimize the 
potential for fraudulent transactions. Common 
examples in use today include asking for several 
forms of identifying information and checking that 
information against databases, asking challenge 
questions based upon credit bureau or other 
information, or sending the consumer a specific piece 
of information, either online or offline, and then 
asking the consumer to verify that information as a 
second step in the authentication process. 

Some other factors to consider in selecting an 
authentication method that is commercially 
reasonable include typical transaction amount, type 
of goods offered, method of delivery, and control of 
goods or funds. It is important to note that it will 
never be considered commercially reasonable to have 
done nothing. Similarly, assigning a password and 
allowing the Receiver to use that password in the 
same Internet session as the sole method of 
authenticating the Receiver is also not commercially 
reasonable. 



Fraudulent Transaction Detection Systems 

Deploying fraudulent transaction detection systems to 
screen WEB entries reduces the potential for 
fraudulent ACH transactions. Fraudulent transaction 
detection systems employ different methodologies 
and different features at varying costs. The choice of 
which features should be included in a fraudulent 
transaction detection system for a particular 
Originator is generally a decision to be made by the 
Originator. 

Examples of fraudulent transaction detection systems 
are systems that track payment history, behavior, 
purchase type, delivery information, etc. Factors to 
consider when choosing a fraudulent transaction 
detection system include the number of transactions 
processed by the Originator, the average dollar size 
of each transaction, the typical relationship with the 
consumer (previously existing or new), and the type 
of goods or services being sold. A fraudulent 
transaction detection system must be deployed no 
matter how small the transaction amount or type. 

Verification of Routing Numbers 

Many WEB entries will be Single-Entry payments, 
and Receivers will frequently enter their routing 
numbers manually using a keyboard. For these 
reasons, exception processing related to WEB entries 
may increase. To minimize exception processing 
related to WEB entries, each Originator is required to 
employ commercially reasonable procedures to verify 
that routing numbers are valid. Originators should 
try to ensure that the consumer enters the routing 
number correctly and that it is a valid RDFI routing 
number for ACH transactions. Although the NA CHA 
Operating Rules do not require Originators to verify 
the validity of Receiver account number structures, it 
is strongly recommended that they employ 
procedures to do so. Some of the methods discussed 
below are appropriate to help verify the validity of 
both routing numbers and account number structures. 

Verifying the validity of routing numbers can be 
accomplished as either a component of a fraudulent 
transaction detection system, through a separate 
database or directory (either commercial or 
proprietary), or through other methods devisedby the 
Originator, for example manual intervention such as 
calling the Receiver's financial institution. 

Security of Internet Session 

As with all ACH entries involving the exchange or 
transmission of any banking information (including, 
but not limited to, an Entry, Entry Data, a routing 
number, an account number, and a PIN or other 
identification symbol) over an Unsecured Electronic 
Network, Originators of WEB entries are required to 
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either (1) encryptthe Receiver's banking information 
using a commercially reasonable security technology 
that, at a minimum, is equivalent to 128-bit. RC4 
encryption technology, or (2) transmit the Receiver's 
banking information via a secure session utilizing a 
commercially reasonable security technology that 
provides a level of security that, at a minimum, is 
equivalent to 128-bit RC4 encryption technology. 
The use of such encryption technology must, at a 
minimum, be employed prior to the key-entry of the 
Receiver's banking information and through the 
transmission of the data to the Originator. 

Currently, 128-bit RC4 encryption technology is the 
standard for financial transactions and is considered 
commercially reasonable. If technological 
advancements drive the commercially reasonable 
standard to change, Originators should comply with 
the new standard. 

Annual Security Audits 



Data loss or compromise not only hurts the 
consumer, but also damages the merchant's 
reputation. Consumer trust is a key factor in building 
loyalty to merchants. It is in the Originator's best 
interest to develop and deploy practices that protect 
the integrity of Receiver information and the 
transaction, and to ensure that these practices are 
audited for their effectiveness. The NA CHA 
Operating Rules for WEB transactions require 
Originators to conduct an audit at least once a year to 
ensure that Receivers' financial information is 
protected by security practices and procedures that 
ensure that the financial information that the 
Originator obtains from consumers is protected by 
security practices that include adequate levels of: 1) 
physical security to protect against theft/tampering, 
or damage, 2) personnel and access controls to 
protect against unauthorized access and use, and 3) 
network security to ensure secure capture, storage 
and distribution of financial information. Such an 
audit must be completed annually. 

This audit requirement can be met in several ways. 
It can be a component of a comprehensive internal or 
external audit, or it can be an independent audit or 
security seal program that covers these security 
issues. An Originator that is already conducting an 
audit of these practices and procedures for another 
area of its business is not required to have two 
separate audits. As long as the audit covers these 
components, it will meet the requirement. 

While the NA CHA Operating Rules only require 
Originators to conduct an audit of their security 
practices and procedures once a year, many 
companies are now opting to audit these practices bi- 
annually or even quarterly due to the rapid change of 
technology and security risks. It is therefore highly 



recommended that Originators of WEB entries also 
conduct more frequent audits. 

The following sections detail the minimum 
components that need to be audited in order to be in 
compliance with the audit requirement. (Note: In 
any case where these key components are not 
specifically required under the NACHA Operating 
Rules, all are recommended by NACHA as sound 
business practices.) 

(1) Physical security to protect against theft, 
tampering or damage 

- Critical network, server, and 
telecommunications equipment should be 
placed in physically secure locations that 
permit access only to authorized personnel. 

- Firewalls must be fully deployed with 
secured processes for administering those 
firewalls. 

- Firewalls must protect websites from 
inappropriate and unauthorized access . 

'■'..- Disaster recovery plans must be developed 
and reviewed periodically. 

(2) Personnel and access controls to protect against 
unauthorized access and use 

- A formal set of security policies and 
procedures must be developed that clearly 
outline the corporate rules governing access 
to sensitive financial data. 

- Hiring procedures should be developed that 
will, at a minimum, verify application 
information and check references on new 
employees that will have access to Receiver 
financial information. 

- Relevant employees must be educated on 
information security and company practices 
and their individual responsibilities. 

- Access controls should be in place to: 

> Limit employee access to secure areas 
and to documents/files that contain 
Receiver financial information. 

> Ensure that terminated employees have 
no access to secure information and 
areas. 

> Permit visitors to these areas and 
information only when absolutely 
necessary and ensure they are 
accompanied by an employee at all 
times. 
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► Restrict access from external networks 
to authenticated users (i.e. by 
passwords or login codes). 

► Ensure that one person acting alone 
cannot circumvent safeguards, i.e. dual 
control procedures are in place. 

- Procedures and audit trails need to be 
established to scrutinize activities of users 
with access to Receiver information in order 
to detect anomalies. 

(3) Network security to ensure secure capture, 
storage and distribution 

'■■■■- All Receiver financial information should 
be kept behind firewalls and in an area 
inaccessible from the Internet. 

- A data retention schedule should be 
developed that covers the policies on how to 
handle the data from the time of capture to 
destruction. 

- Retention schedules should be monitored to 
ensure that they are being met. 

- Receiver information should only be stored 
permanently if it is required by law, 
regulation, rule, or a governing 
organization. 

- Data should not be stored longer than 
necessary. 

- Distribution of Receiver data should be 
limited, with procedures and controls in 
place governing how it is distributed. 



■'■ - The need for distributing Receiver data 
should be reviewed, and all distribution is 
verified and approved. 

— Receiver data sent across networks must be 
encrypted. 

- Use and regularly update anti- virus 
software. 

— Regularly test security systems and 
processes. 

It is important to note that for transactions that involve 
some use of the Internet but are not defined as WEB 
transactions, Originators are encouraged to incorporate 
the security and risk management principles of the WEB 
rules, as applicable. For example, it would still be 
advisable for the Originator to authenticate the Receiver 
and conduct a security audit to ensure the Receiver's data 
is stored securely. 



G. RESPONSIBILITIES OF ODFIs 

1. AGREEMENTS WITH ORIGINATORS 

Each ODFI that chooses to transmit WEB entries on 
behalf of its Originators should consider modifications to 
its agreements with its Originators to address the 
origination of these entries. These modifications should 
address the extent to which the Originator and ODFI will 
share liability for WEB transactions and should define any 
specific processing obligations relating to such 
transactions. For example, the NACHA Operating Rules 
for WEB entries require ODFIs to establish, monitor, and 
review periodically, specific exposure limits for their 
Originators that are initiating WEB entries. Therefore, 
any agreement between the ODFI and the Originator 
should state the appropriate exposure limit and any 
policies and procedures concerning the review and 
monitoring of those limits. 

In addition, these agreements should address the 
procedures, practices, and systems Originators are using 
to comply with their obligations under the NACHA 
Operating Rules governing WEB entries. For example, 
the agreement may need to address the authentication 
methods and the fraudulent transaction detection systems 
the Originators are using for WEB entry transactions. 
Furthermore, ODFIs may want to see proof of the 
Originator's annual security audit prior to or as a 
condition of transmitting WEB entries for the Originator. 

2. WARRANTIES AND LIABILITIES 

In addition to all other ODFI warranties contained within 
the NACHA Operating Rules, each ODFI that chooses to 
transmit WEB entries on behalf of its Originators also 
warrants that: 

• Each Originator for which the ODFI transmits WEB 
entries has employed a commercially reasonable 
fraudulent transaction detection system to screen the 
entry; 

Each Originator of WEB entries has employed 
commercially reasonable methods of authentication 
to verify the identity of the Receiver. 

Each ODFI has established procedures to monitor, on 
an on-going basis, the credit-worthine ss of the 
Originator or Third-Party Sender, has established an 
exposure limit for each Originator or Third-Party 
Sender of WEB entries, has implemented procedures 
to review that limit periodically, and has established 
procedures to monitor entries sent or transmitted by 
the Originator or Third-Party Sender against those 
exposure limits across multiple settlement dates; 

Each Originator has taken commercially reasonable 
steps to verify that routing numbers are valid; 
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Each Originator has conducted an annual audit to 
ensure that the financial information that the 
Originator obtains from consumers is protected by 
security practices that include adequate levels of: 1) 
physical security to protect against theft, tampering, 
or damage, 2) personnel and access controls to 
protect against unauthorized access and use, and 3) 
network security to ensure secure capture, storage 
and distribution of financial information. 

ODFIs need to know their Originators and monitor WEB 
entries because they can be inherently more risky than 
other types of ACH entries. All of these additional 
warranties should be explicitly addressed in ODFI 
agreements with Originators. Because there is a 
commercially reasonable standard that applies to several 
of the warranties, ODFIs need to be aware of what 
procedures, practices, and systems their Originators have 
deployed to meet those requirements. 

3. FORMATTING REQUIREMENTS 

As with all ACH entries, ODFIs must ensure that, prior to 
transmission to the ACH Operator, WEB entries comply 
with all technical specifications and formatting 
requirements in accordance with the NA CHA Operating 
Rules. ODFIs must ensure that: 

• the mnemonic "WEB" appears within the Standard 
Entry Glass Code Field of the Company/Batch 
Header Record; 

• an indicator code of "R" or "S" is placed in the 
Payment Type Code Field of the Entry Detail Record 
to indicate whether the transaction is a recurring or 
Single-Entry payment. This Payment Type Code can 
be used by ACH participants to know which type of 
WEB entry applies to the transaction and also enables 
the RDFI to utilize the appropriate stop payment time 
frame and return reason codes; and 

a WEB entry may be accompanied by one optional 
addenda record (type "05"). 

4. RETURN OF WEB ENTRIES 



WEB entries, like other ACH entries, may be returned for 
a variety of valid reasons in accordance with the return 
time frames prescribed by the NACHA Operating Rules. 
ODFIs should be aware that RDFIs are prohibited from 
returning Single-Entry WEB entries based on a 
consumer's claim thathis authorization has been revoked. 
This is because these are one-time payments, and the 
Originator would likely have acted on the authorization in 
a time and manner that would not allow the consumer an 
opportunity to revoke the authorization before the entry 
has been processed. The consumer retains the option, 
however, to' (1) request his RDFI to stop payment on a 
WEB entry (Return Reason Code R08), (2) request his 
RDFI to return an unauthorized WEB entry (Return 



Reason Code RIO), (3) contact the Originator (if it is a 
merchant) directly to request a refund for the transaction, 
or (4) for recurring WEB entries, request his RDFI to 
return a WEB entry authorization revoked (Return Reason 
CodeR07). 

It is possible that occasionally the financial information 
the Receiver provides to the Originator for a WEB entry 
will be incorrect. When this occurs, the entry may be 
returned using the Return Reason Code R03 (No Account 
/ Unable to Locate Account) or R04 (Invalid Account 
Number). In this situation, the ODFI must handle the 
return according to its agreement with the Originator. 

5. STOP PAYMENTS ON WEB ENTRIES 

ODFIs should be aware that for recurring WEB entries, 
1fa NACHA Operating Mesxe^ 
payments require consumers to place a stop payment 
order on a debit at least three banking days prior to the 
scheduled date of the entry. However, because the 
Originator will generally process Single-Entry WEB 
transactions quickly, consumers are unlikely to be able to 
meet the three day advance notice requirement for placing 
a stop payment order on such entries. To ensure that a 
consumer has the ability to place a stop payment order on 
a Single-Entry WEB entry, the NACHA Operating Rules 
allow a consumer to provide a stop payment order for 
Single-Entry WEB entries to his financial institution so 
long as it is given in such a time and manner that allows 
the RDFI a reasonable opportunity to act on the stop 
payment order prior to acting on the debit entry. 

H. RESPONSIBILITIES OF RDFIs 

1. RETURN OF WEB ENTRIES 

WEB entries may be returned for a variety of valid 
reasons in accordance with the requirements of the 
NACHA Operating Rules, With the exception of entries 
for which the consumer claims there was no authorization, 
the RDFI must transmit WEB entry returns by its ACH 
Operator's deposit deadline for the return entry to be 
made available to the ODFI no later than the opening of 
business on the second banking day following the 
settlement of the original entry. For an entry that the 
consumer claims is unauthorized (Return Reason Code 
RIO), the RDFI must transmit the return by its ACH 
Operator's deposit deadline for the return to be made 
available to the ODFI no later than the opening of 
business on the banking day following the sixtieth 
calendar day following the settlement date of the original 
entry. For the return of unauthorized entries, the RDFI 
must obtain a written statement under penalty of perjury 
from the consumer stating that the entry was not 
authorized. (Note: For additional information on written 
statements under penalty of perjury, refer to the chapter 
on RDFIs in Section II of these Guidelines.) 
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RDFIs must be aware that they are prohibited from 
returning Single-Entry WEB entries using Return Reason 
Code R07 (Authorized Revoked by Customer) based on 
a consumer's claim that his authorization had been 
revoked. This is because these are one-time payments, and 
the Originator would likely have acted on the 
authorization in a time and manner that would not allow 
the consumer an opportunity to revoke the authorization 
before the entry has been processed. 

2. STOP PAYMENTS ON WEB ENTRIES 

For recurring WEB entries, the NACHA Operating Rules 
regarding ACH stop payments require consumers to place 
a stop payment order on a debit at least three banking 
days prior to the scheduled date of the entry. However, 
because the Originator will generally process Single-Entry 
WEB transactions quickly, consumers are unlikely to be 
able to meet the three day advance notice requirement for 
placing a stop payment order on such entries. To ensure 
that a consumer has me ability to place a stop payment 
order on a Single-Entry WEB entry, ±e NACHA 
Operating Rules allow a consumer to provide a stop 
payment order to his financial institution so long as it is 
given in such a time and manner that allows the RDFI a 
reasonable opportunity to act on the stop payment order 
prior to acting on the debit entry. 



SECTION IV 
SPECIAL TOPICS 



B. LEGAL FRAMEWORK 



CHAPTER XV 

TELEPHONE-INITIATED ENTRIES 

A. INTRODUCTION 

Originators of a Single-Entry consumer debit transaction 
are permitted by the NACHA Operating Rules to obtain 
the consumer's authorization for that debit entry, 
including the banking information, orally via the 
telephone. An entry based upon a consumer's oral 
authorization must utilize the TEL (Telephone-Initiated 
Entry) Standard Entry Class Code. This Standard Entry 
Class Code enables ACH participants to readily identify 
Single-Entry transactions that are initiated pursuant to a 
consumer's oral authorization via the telephone. These 
rules streamline the ACH authorization process by 
providing an alternative method for obtaining the 
consumer's authorization for Single-Entry ACH debit 
activity, facilitating use of the ACH Network for one-time 
payments. Because TEL entries are Single-Entry debits, 
Originators must be aware that they must obtain a separate 
oral authorization from the consumer for each entry to the 
consumer's account. 



TEL entries are subject to the requirements of the NA CHA 
Operating Rules and the Electronic Fund Transfer Act as 
implemented by the Federal Reserve Board's Regulation 
E. While Regulation E covers both recurring and non- 
recurring ACH debit entries, the Regulation does not have 
specified requirements for the authorization of non- 
recurring ACH debit entries, 

c.tel entries 



A TEL entry is an entry initiated by an Originator in 
response to a consumer's oral authorization, which 
includes the consumer's banking information, captured via 
the telephone to transmit a' Single-Entry ACH debit to his 
account to collect payment for goods or services. A 
Single-Entry is a one-time transfer of funds initiated by 
the Originator in accordance with the Receiver's 
authorization. Originators may not utilize this Standard 
Entry Class Code to transmit credit entries, with the 
exception of reversals, to the consumer's account. 

A TEL entry should not be initiated in situations where 
the consumer has provided the Originator with a standing 
authorization for the transmission of multiple but non- 
recurring ACH debit entries to his account (e.g., the 
consumer has provided a written authorization to his 
brokerage firm to debit the consumer for occasional 
securities purchases). Although the purchase may be 
transacted via telephone, authorization and banking 
information were provided via a separate written 
authorization. In this situation, ACH debit activity should 
be originated using the PPD Standard Entry Class Code as 
defined by the NACHA Operating Rules. 

A TEL entry may be transmitted only in circumstances in 
which ( 1 ) there is an existing relationship between the 
Originator and the consumer, or (2) there is not an 
existing relationship between the Originator and the 
consumer, but the consumer has initiated the telephone 
call to the Originator. A TEL entry may not be used by an 
Originator when there is no existing relationship between 
the Originator and the consumer, and the company has 
initiated the telephone call. The Originator and the 
consumer are considered to have an existing relationship 
when either (1) there is a written agreement in place 
between the Originator and the consumer for the provision 
of goods or services (e.g. , the consumer has an insurance 
policy with the Originator), or (2) the consumer has 
purchased goods or services from the Originator within 
the past two years. For purposes of these Rules, an 
affiliate of an Originator that has an existing relationship 
with a Receiver is not deemed to have such an existing 
relationship with the Receiver with respect to TEL entries. 

TEL Risk Concerns 

While the TEL application was developed to provide a 
more streamlined method by which consumers could 
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authorize one-time ACH debit entries, with this 
streamlined authorization process comes the potential for 
misuse through the origination of unauthorized ACH debit 
transactions. Many of these entries are originated as a 
result of deceptive and fraudulent telemarketing practices. 
Examples of the types of complaints that have been 
reported concerning misuse of TEL entries are described 
below: 

Merchants operating with fraudulent intent debit the 
consumer without having obtained the consumer's 
authorization for such a transaction; 

.•■;■. ■ Merchants operating with fraudulent intent violate the 
rules governing TEL entries by cold calling 
consumers with whom they have no existing 
relationship and subsequently debiting the consumer; 
and 



consider monitoring returns for unauthorized TEL 
entries in an effort to quickly identify areas of 
potential fraud; and 



•.■;■■■ Merchants operating within the boundaries of the 
TEL rules by using mail solicitations to instruct the 
consumer to initiate the telephone call to the 
merchant and subsequently attempting to sell their 
wares using deceptive marketing practices. 

A correlation has been established between high return 
rates relating to unauthorized debits and Originators that 
are violating the NACHA Operating Rules or that are 
engaged in fraudulent/deceptive marketing practices. 
Such merchants typically experience a volume of 
unauthorized returns in excess of the average for 
unauthorized debit entries. Because ODFIs are 
responsible for all transactions they initiate into the ACH 
Network, they must recognize that they are exposed to 
substantial risk when offering origination services on 
behalf of merchants engaged in fraudulent or deceptive 
business practices. To minimize the potential for fraud, 
GDFIsshould: 

•■'. ensure that they know their customers and are 
familiar with their business practices; 

• ensure that, when the ODFI's customer is a Third- 
Party Service Provider, the ODFI has entered into 
contractual agreements with the ultimate Originators 
of the transactions and that it is familiar with the 
business practices and risks associated with 
originating entries on behalf of each individual 
Originator; 

• ■ .- . understand that offering direct access to the ACH 

Operator adds risk to the ODFI. The ODFI remains 
responsible for all transactions originated under its 
routing number but may have no knowledge of the 
types or dollar values of payments being originated. 
The ODFI should ensure that they have established 
monitoring capabilities to examine entries entered 
into the ACH Network under its routing number and 
to restrict the origination of any files that seem 
questionable; 



• consider excluding certain types ofbusiness activities 
from use with the TEL application as they may be 
riskier and are likely to result in an excessive rate of 
returns. 

D. OBLIGATIONS OF ORIGINATORS 

1. AGREEMENTS WITH ODFIs 

Originators desiring to use the ACH Network to transmit 
TEL entries should consider modifications to their 
agreements with their ODFIs to address the origination of 
this type of transaction. At a mimmum, additions to the 
ODFI/Originator agreement should include the 
Originator's responsibilities and obligations with respect 
to the provision of specific information to the consumer 
during the telephone call, the Originator's requirement to 
tape record or provide written confirmation of the 
consumer's authorization, verification of the identity of 
the Receiver, and verification of routing numbers. -As the 
ODFI assumes additional warranties with respect to the 
verification of the consumer's identity and verification of 
the consumer's routing number, the agreement should also 
address the extent to which the Originator and ODFI will 
share liability for any failure on the part of the Originator 
to comply with these and other requirements of the 
NACHA Operating Rules. 

2: AUTHORIZATION REQUIREMENTS 

As with other ACH entries, Originators of TEL entries 
must obtain the consumer's explicit authorization prior to 
initiating a debit entry to a consumer's account Unlike 
other debit entries to a consumer's account, however, 
Originators need not provide the consumer with a written 
authorization for the consumer to sign or similarly 
authenticate. Instead, the Originator may obtain the 
consumer's authorization for a TEL entry orally via the 
telephone. Originators of TEL entries are obligated either 
to tape record the consumer's oral authorization or to 
provide, in advance of the Settlement Date of the entry, 
written notice to the consumer that confirms the oral 
authorization. The Receiver must be provided, and must 
acknowledge, the following terms of the transaction: 

•'.■ the date on or after which the consumer's account 
will be debited; 

v the amount of the debit entry to the consumer ' s 
account; 

the consumer's name; 

• a telephone number that is available to the consumer 
and answered during normal business hours for 
customer inquiries; 
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• the date of the consumer's oral authorization; and 

• a statement by the Originator that the authorization 
obtained from the Receiver will be used to originate 
an ACH debit entry to the consumer's account. 

For an oral authorization obtained over the telephone to 
be in accordance with the requirements of the NACHA 
Operating Rules, (1) the Originator must state clearly 
during the telephone conversation that the consumer is 
authorizing an ACH debit entry to his account, (2) the 
Originator must express the terms of the authorization in 
a clear manner, and (3) the Receiver must unambiguously 
express consent. Silence is not express consent. The 
Originator must retain either the original or a duplicate 
tape recording of the consumer' s oral authorization or a 
copy of the written notice confirming the consumer's oral 
authorization for two years from the date of the 
authorization. At the request of the ODFI, the Originator 
must provide a copy of the consumer's authorization. 



An Originator that chooses the option to provide the 
consumer with written notice confirming the consumer's 
oral authorization must disclose to the consumer during 
the telephone call the method by which such notice will be 
provided. The written notice must include, at a minimum, 
the six pieces of information required to be disclosed 
during the telephone call, as described above. Originators 
should understand that the term "provide" is intended to 
mean that the Originator has utilized a medium (e.g., U.S. 
mail, fax, or other mail delivery method) to send the 
written notice to the consumer. (Note: Any written notice 
or disclosure required by the NACHA Operating Rules 
may be provided in electronic form, including e-mail. 
This includes the notice for TEL. Please note, however, 
that state and federal laws may require consumer consent 
before using electronic notices/disclosures.) The term 
"provide" does not imply receipt of such notice by the 
consumer. Originators must understand that, when written 
notice is used to confirm the authorization, the consumer 
must be afforded the right to contact the Originator, using 
the telephone number provided, to correct any erroneous 
information contained within the notice. (NOTE: 
Compliance with the NACHA Operating Rules does not 
eliminate the obligation to comply with other applicable 
laws.) 

An Originator using a voice response unit ( VRU) to 
capture a consumer's authorization for a TEL entry must 
understand that key-entry responses by the consumer to 
input data and to respond to questions does not qualify as 
an oral authorization. A VRU may be used by the 
consumer to key enter data and to respond to questions, 
provided that the actual authorization by the consumer is 
provided orally. 



3. RISK MANAGEMENT 

In an effort to minimize the risk related to Telephone- 
Initiated Entries, in which the identity of the consumer 
and the consumer's assent to the authorization cannot be 
assured by a written authorization, the NACHA Operating 
Rules require Originators to implement a number of 
specific risk management procedures relating to TEL 
entries: 

9 Verification of Identity of Receiver 

Originators of TEL entries are required to utilize 
commercially reasonable procedures to verify the 
identity of the consumer. Originators will need to 
establish a commercially reasonable method (e.g., use 
of a directory, database, etc.) to verify the consumer's 
name, address, and telephone number. The 
Originator is also advised to further verify the 
Receiver 's identity by verifying pertmentMormation 
with the Receiver (e.g., past buying history, mother's 
maiden name, Caller ID information, etc.). 

V Verification of Routing Numbers 

Each Originator that initiates TEL entries must 
establish commercially reasonable procedures to 
verify that routing numbers are valid. Because TEL 
entries are Single Entry debits where consumers will 
provide their routing numbers by reading them from 
a source document (e.g., the consumer's check), there 
are likely to be circumstances in which the routing 
number is provided by the consumer incorrectly. 
Similarly, there may be situations in which the MICR 
information on the consumer's check is not 
appropriate for ACH processing. As a result, 
exception processing related to TEL entries may 
increase. To minimize the potential for exception 
processing with respect to these transactions, each 
Originator is obligated to employ commercially 
reasonable procedures to verify that routing numbers 
are valid. Verification of the validity of the entry's 
routing number can be accomplished through the use 
of a database or directory (either commercial or 
proprietary), or through other methods devised by the 
Originator. The validity of the entry's routing 
number may also be verified by manual intervention 
such as contacting the consumer's financial 
institution. Although the NACHA Operating Rules 
do not require verification of the structure of the 
consumer's account number, Originators are 
encouraged to establish similar procedures to validate 
this information prior to the transmission of TEL 
entries. 

A commercially reasonable system, technology, practice, 
or procedure is one that corresponds to commonly 
;pted commercial practices among commonly situated 
Senators conducting similar types of business. In other 



accei 



accepted commercial practices among commonly situated 
Originators conducting similar types of business. In othei 
words, the concept of "commercial reasonableness' 1 
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means that an Originator, given the facts of a specific 
transaction, acted in a way that other similar Originators 
would have acted. The determination of commercial 
reasonableness is based on the situation of each Originator 
with respect to a number of factors including the size, 
type, and frequency of entries typically transmitted by the 
Originator, the alternatives available to the Originator, 
and procedures in general use by similarly situated 
Originators. Whether an Originator has fulfilled its 
obligations to perform in a commercially reasonable 
manner will be determined based on an evaluation of 
those circumstances, including a weighing of the cost to 
the Originator to employ a particular technology or 
procedure against the level of protection it affords to the 
Originator and other ACH participants. A party 
challenging the Originator that the use of a particular 
system, technology, practice, or procedure has the burden 
of proving that it was not commercially reasonable. 

F. OBLIGATIONS OF ODFIs 

1. WARRANTIES AND LIABILITIES 

In addition to all other general ODFI warranties contained 
within the NACHA Operating Rules, each ODFI that 
chooses to transmit TEL entries on behalf of its Originator 
also warrants that; 

each Originator for which it transmits TEL entries 
has employed commercially reasonable procedures to 
verify the identity of the Receiver; and 

V each Originator transmitting TEL entries has utilized 
commercially reasonable procedures to verify that 
each routing number is valid. 

2. RETURN OF TEL ENTRIES 

ODFIs should understand that TEL entries may be 
returned by the RDFI for any valid reason. RDFIs are 
subject to the typical return time frames for transmitting 
TEL entry returns. Specifically, an RDFI must transmit a 
returned TEL entry to its ACH Operator by the ACH 
Operator's deposit deadline for the return entry to be 
made available to the ODFI no later than the opening of 
business on the second banking day following the 
settlement date of the TEL entry. 

In the event that a consumer claims that he did not 
authorize the Originator to transmit a TEL entry, the 
RDFI may transmit a return for the TEL entry to its ACH 
Operator by the ACH Operator's deposit deadline for the 
return to be made available to the ODFI no later than the 
opening of business on the banking day following the 
sixtieth calendar day following the settlement date of the 
TEL entry. In circumstances in which an entry was not 
authorized, the RDFI must obtain a written statement 
under penalty of perjury from the consumer before re- 
crediting the consumer's account and returning the entry. 
Any subsequent dispute regarding an unpaid debt must be 



addressed between the Originator and Receiver outside of 
the ACH return process. (Note: For additional 
information on written statements under penalty of 
perjury, refer to the chapter on RDFIs in Section II of 
these Guidelines.) 

ODFIs should be aware that an RDFI is not permitted to 
return a TEL entry using Return Reason Code R07 
(Authorization Revoked by Consumer). Because such 
transactions are one-time payments that are authorized at 
the time goods or services are purchased, the Receiver is 
precluded from revoking authorization for the transaction. 
ODFIs must understand, however, that the consumer 
retains his right to place a stop payment order on a TEL 
entry. The consumer may also request the return of any 
unauthorized TEL entry using Return Reason Code RIO 
(Customer Advises Not Authorized). The consumer may 
also seek a refund for a transaction directly with the 
Originator. 

3. ■ TEL ENTRY REPORTING REQUIREMENTS 

ODFIs are required, upon receipt of a written request from 
the National Association, to provide the National 
Association with specific information relating to all 
Originators of TEL entries whose return rate for those 
transactions that are returned as unauthorized appears to 
exceed 2.5%. This requirement provides an additional 
mechanism that ACH participants can use to identify 
problem Originators and react to the origination of 
unauthorized payments via the ACH Network. 

For each Originator of TEL entries using the ODFI 
directly or originating such transactions through a Third- 
Party Service Provider, the ODFI must provide the 
following information: 

.•■ the acmal return rate for unauthorized TEL entries for 
any Originator. Such return rate must be calculated 
either by 

(1) dividing the number of TEL entries returned as 
unauthorized for the preceding 60 days by the 
total number of TEL entries contained within the 
file in which the original entries were 
transmitted; or 

(2) dividing the number of TEL entries returned as 
unauthorized by the total number of TEL entries 
originated for the preceding 60 days. 

• where the Originator's return rate for TEL entries 
that are returned as unauthorized exceeds 2.5%, the 
ODFI must also provide 

(1) the name, address, telephone number, contact 
person, principal owner(s), and taxpayer 
identification number of the Originator, and, if 
applicable, each Third-Party Service Provider 
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acting on behalf of the Originator with respect to 
the origination of TEL entries; 

(2) a general description of the nature of the 
business of the Originator; and 

(3) an explanation of the Originator's reason(s) for 
the excessive rate of return. 

Each ODFI must provide the requested information to the 
National Association within ten banking days of receipt of 
the National Association's written request to the ODFI's 
Chief Operating Officer. The failure of an ODFI to 
provide such information in a timely manner is considered 
to be willful disregard of the NAGHA Operating Rules 
and may result in the imposition of a fine against the 
ODFI. 

ODFIs should understand that, while the 2.5% return rate 
is the threshold above which the number of returns for 
unauthorized is considered excessive for purposes of 
requiring reporting to NACHA, neither the ODFI nor its 
Originators should consider such a return rate an 
acceptable one for normal business purposes. ODFIs 
should strive to ensure that their Originators ' actual return 
rate for unauthorized entries remains at or below the 
industry return rate for unauthorized PPD debits entries, 
which currently averages 0.10%. ODFIs should also be 
aware that the 2.5% threshold will be re-evaluated on a 
regular basis to determine whether a lower threshold is 
appropriate. 

(Note: This rule applies only to those ODFIs that have 
been identified by NACHA as having a problem with an 
excessive number of TEL entries returned as 
unauthorized. These requirements do not impact all 
ODFIs generally. It is, however, good business practice 
for all ODFIs to monitor their return rates in order to be 
proactive in identifying problem areas in their ACH 
origination.) 

F. OBLIGATIONS OF ROTTs 

1. RETURN OF TEL ENTRIES 

RDFIs are subject to the typical return time frames for 
transmitting TEL entry returns. Specifically, an RDFI 
must transmit a returned TEL entry to its ACH Operator 
by the ACH Operator's deposit deadline for the return 
entry to be made available to the ODFI no later than the 
opening of business on the second banking day following 
the settlement date of the TEL entry. 

In the event that a consumer claims that he did not 
authorize the Originator to transmit a TEL entry, the 
RDFI may transmit a return for the TEL entry to its ACH 
Operator by the ACH Operator's deposit deadline for the 
return to be made available to the ODFI no later than the 
opening of business on the banking day following the 
sixtieth calendar day following the settlement date of the 



TEL entry. In circumstances in which an entry was not 
authorized, the RDFI must obtain a written statement 
under penalty of perjury from the consumer before re- 
crediting the consumer's account and returning the entry. 
Any subsequent dispute regarding an unpaid debt must be 
addressed between the Originator and Receiver outside of 
the ACH return process. 

RDFIs must understand that a TEL entry may not be 
returned using Return Reason Code R07 (Authorization 
Revoked by Consumer). Because such transactions are 
one-time payments that are authorized at the time goods 
or services are purchased, the Receiver is precluded from 
revoking authorization for the transaction. RDFIs must be 
aware, however, that the consumer retains his right to 
place a stop payment order on a TEL entry. The 
consumer may also request the return of any unauthorized 
TEL entry using Return Reason Code RIO (Customer 
Advises Not Authorized). The consumer may also seek a 
refund for a transaction directly with the Originator. 

2. STOP PAYMENTS ON TEL ENTRIES 

In general, foe NACHA Operating Rules regarding ACH 
stop payments require consumers to place a stop payment 
order on a debit at least three banking days prior to the 
scheduled date of the entry. However, in the case of TEL 
entries, where an Originator will generally process TEL 
entries quickly, consumers are unlikely to be able to meet 
the three-day advance notice requirement for placing a 
stop payment order on such entries. To increase the 
likelihood that a consumer has the ability to place a stop 
payment order on a TEL transaction, the NACHA 
Operating Rules require a consumer to provide a stop 
payment order to his financial institution in such a time 
and manner mat allows the RDFI a reasonable opportunity 
to act on the stop payment order prior to acting on the 
debit entry. 
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Account holder, returns for death of, OG 75 
Account screening, OF AC regulations, OG 1 15-OG 116 
Accountability. See Settlement and accountability 
Accounts Receivable Entry (ARC) 

about, OG 3, OG 5, OG 177-OG 178 

authorization/notification requirements, OG 1 78-OG 179 

collection fees, OG 179 

copy of source document, OG 182-OG 183 

eligible items, OG 178 

formatting requirements, OG 179, OG 181 

improper debits, OG 23 

legal framework, OG 178 

ODFI agreements, OG 178 

ODFIs arid, OG 36, OG 180-OG 182 

Originators and, OG 26-OG 27, OG 178-OG 180 

RDFIs and, OG 56, OG 61, OG 182-OG 183 

reinitiation of entries, OG 179-OG 180 

return of entries, OG 180, OG 181, OG 182 

returns for unauthorized/improper consumer debits, OG 74, OG 85 

source document retention, OG 180, OG 182 

statement requirements, OG 183 

stop payments, OG 180, OG 181, OG 182 

warranties and liabilities, OG 180 
ACH. See Automated Clearing House 
ACH files' 

ODFI delivery of, OG 38 

sample applications and assumptions, OG 13 5-OG 142 
ACH Operators. See Automated Clearing House (ACH) Operators 
ACK/ATX, See Acknowledgment Entries 
Acknowledgment Entries (ACK/ATX) 

about, OG 6 

definition, OG 91 

ODFI and, OG 35, OG 92 

Originators arid, OG 26, OG 91-OG 92 

RDFIs and, OG 56, OG 92 

refused, OG 92 
Addenda Records 

about, OG105-OG 106 

basic ASC X12 rules, OG 109-OG 1 1 1 

CCD,OG106 

CIEsand,OG94 

consumer payments, OG 108-OG 109 

corporate payments, OG 106-OG 108 

CTX, OG 106-OG 108 

data segment diagram key, OG 1 1 1-OG 112 

ENR, OG 81-OG 82, OG 109, OG 158 

PPD,OG 108-OG 109 

RDFI output, OG 108 

RDFI processing, OG 53-OG 54 
ADV. See Automated Accounting Advice 
ANSI ASC X12 messages, OG 2-OG 3 
ANSI ASC X12 rules, OG 109-OG 1 1 1 
ANSI ASC X12.4 Payment Order/Remittance Advice, OG 2-OG 3 
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Arbitration 

about, OG 130 

cross-border payments, OG 164 

procedures, OG 130-OG 133 
ARC. See Accounts Receivable Entry 

ATX. See Acknowledgment Entries; Financial EDI Acknowledgment 
Audit controls and compliance 

about, OG117-OG 118 

administrative controls, OG 11 7-OG 118 

compliance checklist, OG 12 1-OG 122 

internal operating control points, OG 11 8-OG 121 

ODFIs,OG 102-OG 104, OG 118-OG 120, OG 121-OG 122 

RDFIs, OG 102, OG 104-OG 105, OG 120-OG 121, OG 122 

rules enforcement, OG 122 

Third-Party Service Providers, OG 102-OG 105, OG 1 17 
Audit requirements '■ V'- 

ODFIs, OG 40-OG 42 

RDFIs, OG 62-OG 63 

Third-Party Service Providers, OG 40-OG 42, OG 62-OG 63 
Audittrails 

ACH Operators, OG 48 

Third-Party Service Providers, OG 100 
Automated Accounting Advice (AD V) 

about, OG6 
Automated Clearing House (ACH) Network, OG 2 

OFACand,OG113 
Automated Clearing House (ACH) Operators 

about, OG 2, OG 43 

ACH file delivery, OG 46-OG 47 

adherence to NA CHA Operating Rules, OG 43 

agreements, OG 43-OG 45 

audittrails, OG 48 

automated returns, dishonored returns, and contested dishonored returns, OG 78 

batch rejection, OG 47-OG 48 

compliance with and performance of rules, OG43 

definition, OG 4, OG 43 

electronic signatures and records, OG 43-OG 44 

ENR returns, OG 78, OG 157 

entry level rejection, OG 47-OG 48 

evaluation of credit- worthiness and risk control measures, OG 48 

Federal Reserve Policy Statement on Privately-Operated Multilateral Settlement Systems, OG 49 

file acknowledgments, OG 47 

file editing, OG 47 

file rejection, OG 47-OG 48 

file security, OG 46 

inter-ACH Operator exchange, OG 46 

ODFIs and, OG 44-OG 45, OG 46-OG 47 

Participating DFI profile and, OG 45 

performance standards, OG 49 

processing functions, OG 47-OG 48 

RDFIs and, OG 44 

record retention, OG 44 

rejected entries, OG 47-OG 48 

relationship with DFIs, OG 44 

relationship with ODFI, OG 38-OG 40 

release of return data by, OG 126 

returns by other ACH participants and, OG 78 

settlement functions, OG 44, OG 45, OG 48, OG 49 
Automated Clearing House (ACH) System 

advantages to participants, OG 6-OG 7 

development of; OG 2-OG 3 



OG 196 



2005 OPERATING GUIDELINES INDEX 

overview of, OG 4-OG 7 

participants, OG 4 

payment applications, OG4-OG 6 
Automated Enrollment Entry (ENR) 

about, OG 3, OG 6, OG 154 

Addenda Records, OG 109, OG 158 

Addenda Records, return reason codes, OG 81 -OG 82 

definition, OG 154 

DFI responsibilities, OG 154-OG 159 

format requirements, OG 155-OG 157 

origination, OG 154-OG 155 

Originators and, OG 26 

responses to, OG 157 

responsibilities of Federal Government Agencies receiving, OG 159 

return reason codes, OG81 

returned, OG 157-OG 158 

returned by Federal Government Agencies, OG 157, OG 158 

Third-Party Service Provider to originate, OG 157 

timing of origination, OG 155 
Automated Notification of Change or Refused Notification of Change (COR), OG 6 
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Batch rejection, OG 39, OG 47-OG 48 
Beneficiary death, returns for, OG 75 



Benefit payments, reclamations for, OG 90 

Blocked accounts/parties, OF AC regulations and, OG 1 14, OG 1 15, OG 116 



Calwestern Automated Clearing House Association (CACHA), OG 2 
Cash Concentration or Disbursement (CCD) 

about, OG 3, OG 6 

Addenda Records, OG 106 
CBR. See Corporate Cross-Border Payment 
CCD. See Cash Concentration or Disbursement 
CIE. See Customer Initiated Entry 
Collection fees 

ARC Entry, OG 179 

RCK Entry, OG 170 
Commercially reasonable, definition, OG 1 84 
Company/Batch Header Records. See also specific entries by type 

CIEsand,OG94 
Company/Batch Records, OG 2-OG 3 
Compensation 

about,OG 133 

cross-border payments, OG 164 

Deposit Insurance Assessments, OG 134 

minimum claim amount, OG 133 
Complaints. See Arbitration; Report of Possible ACH Rules Violation 
Consumer applications. See also specific applications 

about, OG 5-OG 6 

Addenda Records, OG 108-OG 109 

authorization requirements for, OG 19-OG 22 

RDFIsand, OG60-OG61 

unauthorized/improper consumer entries, OG 22-OG 23, OG 40, OG 60-OG 61, OG 73-OG 74, OG 84-OG 85 
Consumer Cross-Border Payment (PBR) 

about, OG 3, OG 5, OG 167-OG 168 

ODFIand,OG36 

Originators and, OG 26 
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RDFIs and, OG 56 

return reason codes, OG 83 
Contingency notification of delays, cross-border payments, OG 1 64 
COR. See Automated Notification of Change or Refused Notification of Change 
Corporate applications. See also specific applications 

about, OG6 

agreements for, OG 23 

RDFIs and, OG 59-OG 60 

unauthorized corporate entries, OG 39-OG 40, OG 59-OG 60, OG 84 
Corporate Cross-Border Payment (CBR) 

about, OG 3, OG 6, OG 167-OG 168 

ODFIand,OG36 

Originators and, OG 26 

RDFIs and, OG 56 
Corporate Trade Exchange (CTX) 

about, OG 2-OG 3, OG 3, OG 6 

Addenda Records, OG 106-OG 108 
Corporate Trade Payment (CTP) 

about, OG2 

ODFI conversions of ASC X12.4 to, OG 2 
Credit-worthiness and risk control measures, ACH Operator evaluation of, OG 48 
Credits. See also Direct deposit 

authorization requirements, OG 19-OG 20 

entries violating OF AC sanctions, OG 114-OG 115 

RDFIs and, OG57-OG 58 
Cross-border entries 

ODFIand,OG36 

Originators and, OG 26 

RDFIs and, OG 56 

return reason codes, OG 83 
Cross-border payments. See also Consumer Cross-Border Payment; Corporate Cross-Border Payment 

about, OG 16 1-OG 162 

definition of terms, OG 164-OG 165 

foreign exchange, OG 163 

national payment system rules, OG 165-OG 167 

operating rules and agreements, OG163-OG 167 

payment process, OG 162-OG 163 

record retention, OG 1 64 

reference information, OG 1 68 

settlement, OG 163, OG 164 

technical standards, OG 167-OG 168 

transmission of entries, OG 162-OG 1 63 
CTX, See Corporate Trade Exchange 
Customer Initiated Entry (CIE) 

about, OG 2, OG 5, OG 94-OG 94 

Addenda Record and, OG 94 

Company/Batch Header Record and, OG 94 

formatting requirements, OG 94 



Data Element Requirement, OG 109-OG 1 10 
Data Element Types, OG 110 
Data segment diagram key, OG 1 1 1-OG 1 12 
Death Notification Entry (DNE) 

about, OG 3, OG 6 

RDFIs and, OG 54-OG 56 
Death of beneficiary, representative payee, or account holder, returns for, OG 75 
Debits. See also Point-of-Purchase Entry (POP); Point-of-Sale Entry (POS) 

about, OG7 

authentication of authorization, OG20-OG 21 ' 
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authorization agreement, OG 24 

authorization requirements, OG 19-OG 23 

consumer information, OG 21 

copy of authorization, OG 20 

ineligible/improper consumer debits, OG 74, OG 85 

information requirements, OG 2 1 

minimum information requirements, OG20 

multiple, non-recurring, OG21 

NACHA Operating Rules versus Regulation E, OG 86-OG 87 

notice of changes for recurring debits, OG 21 

preauthorized bill payment, OG 5 

RDFIs and, OG57-OG 58, OG 60-OG 61 

retention of authorization, OG 21 

revocation of authorization, OG 21 -OG 22 

sample debit authorization, OG 24 

unauthorized consumer debits, OG 73-OG 74 

unauthorized corporate debits, OG 39-OG 40, OG 84 

unauthorizedVimproper consumer debits, OG 22, OG 40, OG 60-OG 61, OG 73-OG 74, OG 84-OG 85 
Deposit Insurance Assessments, compensation and, OG 134 

Depository Financial Institution (DFI). See also Originating Depository Financial Institution; Receiving Depository 
Financial Institution (RDFI) 

ACH system and, OG 3 

arbitration and compensation, OG 130-OG 134 

ENR responsibilities, OG 154-OG 159 

Participating DFI profile, OG 45 

relationship with ACH Operator, OG 44 
Destroyed Check Entry (XCK) 

about,OG3,OG6,OG159 

legal considerations, OG 15 9-OG 160 

ODFIs and, OG 40 

origination of, OG 160 

RDFIs and, OG 54 

receipt of, OG 1 60-OG 161 
Direct deposit/See also Prearranged Payment and Deposit Entry; Preauthorized bill payment 

about, OG 5, OG 7 

authorization agreement, OG 24 

authorization requirements, OG 1 9-OG 20 
Dishonored returns 

contested dishonored returns, OG 72-OG 73, OG 75, OG 152-OG 154 

originating contested dishonored returns, OG 77-OG 78, OG 87-OG 88 

procedure, OG 72-OG 73, OG 75, OG 76-OG 78 

receiving, OG 87 

sample applications and assumptions, OG 148-OG 151, OG 152-OG 154 
Disputes. See Arbitration 
DNE. See Death Notification Entry 
Duplicate files, reversing, OG OG 88-OG 90 

E ..' ''.■/, 

Electronic data interchange standards. See ANSI ASC X12 messages 
Electronic signatures and records 

ACH Operators and, OG 43-OG 44 

ODFIs and, OG 32 

Originators and, OG 8 

RDFIs and, OG 59 

Third-Party Service Providers and, OG 99 
ENR. See Automated Enrollment Entry 
Erroneous entries 

cross-border payments, OG 1 64 

Third-Party Service Providers, OG 100 
Erroneous files, reversing, OG 88-OG 90 
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Exception handling, RDFIs and, OG 54 
Excused delay, OG 57 
ODFIand,OG38 

F 

Federal Financial Institutions Examination Council (FFIEC), OG 57 

Federal Reserve Banks, OG 43. See also Automated Clearing House (ACH) Operators 

as ACH Operator, OG 43-OG 49 
Federal Reserve Policy Statement on Privately-Operated Multilateral Settlement Systems, ACH Operators and, OG 49 
Federal Reserve System, OG 2 
File acknowledgments, ODFI, OG 39 
File rejection, OG 47-OG 48 
File requirements, ODFI and, OG 37 
File reversals, OG 88-OG 90 
Filesecurity 

ACH Operators, OG 46 

ODFI and, OG 37 

Originators, OG 28 

RDFIs, OG 52 

WEB Entry, OG184-OG 185 
Financial EDI Acknowledgment (ATX). See also Acknowledgment Entries 

Originators and, OG 26 • 

RDFIs and, OG 56 
Financial institution general ledger accounts 

ODFIand,OG36 

Originators and, OG 27 

RDFIs and, OG 50 
Fines. See National System of Fines 
Formatting requirements 

ARCEntry,OG179,OG181 

CIE Entry, OG 94 

ENR Entry, OG 155-OG 157 

POP Entry, OG 174-OG 175, OG 175-OG 176 

RCK Entry, OG 171 

WEB Entry, OG 189 

G 

Gateway operators. See Originating Gateway Operator (OGO); Receiving Gateway Operator (RGO) 

.1 ■ ' ■ 

Inbound entries. See Receiving Gateway Operator 
Input schedules/availability of funds, OG 29 
Insufficient funds, returns for, OG 73 
International ACH transactions, OF AC and, OG 1 13 
Internet-Initiated Entry (WEB) 

about,OG3,OG6,OG183 ' 

authorization requirements, OG 185 

background, OG 183 

definitions, OG 183-OG 184 

file security, OG 184-OG 185 

formatting requirements, OG 189 

legal framework, OG 183 

ODFI agreements, OG 185, OG 188 

ODFIs and, OG 36, OG 1 88-OG 189 

Originators and, OG 27, OG 185-OG 188 

RDFI agreements, OG 188 

RDFIs and, OG 5.7, OG 189-OG 190 
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return' of entries, OG 189-OG 190 
risk management, OG 185-OG 188 
stop payments, OG 189, OG 190 
verification of identity of Originators, OG 185 
warranties and liabilities, OG 188-OG 189 
Invalid characters, OG 29 



Loan accounts 
ODFIand,OG36 
Originators and, OG 27 
RDFIsand,OG50-OG51 

M 

Machine Transfer Entry (MTE), OG 2, OG 5 

Mapping information to ACH formats. See also Sample applications and assumptions 

about, OG 134 

file sequence diagram, OG 134 
MTE. See Machine Transfer Entry 

N ..' .;.'. : 

NACHA Operating Guidelines, OG 1 
NACHA Operating Rules, QG\ 

ACH Operators and, OG 43 

national payment system rules and, OG 165-OG 167 

versus Regulation E, OG 86-OG 87 
National ACH Operator Performance Standards, OG 49 
National Automated Clearing House Association (NACHA), OG 1, OG2 
National payment system rules, cross-border payments, OG 165-OG 167 
National System of Fines, OG 63, OG 122. See also Report of Possible ACH Rules Violation 

ACH Rules Enforcement Panel, OG 126-OG 127 

confidentiality of information, OG 127 

definition, OG 123 

imposition of fines, OG 125-OG 126 

investigation of alleged violations, OG 124-OG 126 

release of return data by ACH Operators, OG 126 

reporting form, OG 123, OG 128-OG 129 

reporting possible violations, OG I23-OG 124 

resolution of complaint, OG 126 
NOC. See Notification of change 
Notification of Change (NOC) 

about, OG 30, OG 39-OG 40 

definition, OG 68 

ODFI responsibilities, OG 7 1-OG 72 

Originator responsibilities, OG 72 

RDFI responsibilities, OG 68-OG 71 

refused, OG70-OG 71, OG 151-OG 152 

returns and NOC entries, sample applications and assumptions, OG 142-OG 154 

Third-Party Service Providers and, OG 101 
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ODFI. See Originating Depository Financial Institution 

Office of Foreign Assets Control (OF AC) regulations, OG 28, OG 33-OG 34, OG 5 1-OG 52 

compliance, OG 112-OG 117 
OGO. See Originating Gateway Operator 
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Originating Depository Financial Institution (ODFI) 

about, OG 30 .' 

ACH payment association membership, OG 30 

acknowledgment entries, OG 35, OG 92 

advantages to, OG 7 

agreements/relationship with Originator, OG 32-OG 34 

agreements/relationship with Third-Party Service Providers, OG 34-OG 35, OG 98-OG 99 

ARC Entry, OG 36, OG 180-OG 182 

audit requirements, OG 40-OG 42 

corrected entries, OG 78 

cross-border entries, OG 36 

definition, OG 4 

delivery agreement with ACH Operator, OG 45, OG 46-OG 47 

delivery of ACH files, OG 38 

dishonored returns, OG 75, OG 76-OG 78 

electronic signatures and records, OG 32 

excused delay, OG38 

exposure limits, OG 34 

file acknowledgments, OG39 

file requirements, OG 37 

file reversals, OG 88-OG 90 

file security, OG 37 

input files, OG 46 

issues to be defined in agreement between Originators and, OG 10-OG 12 

legal considerations, OG 31 -OG 35 

limitations on warranties, OG 32 

NOC responsibilities, OG 7 1-OG 72 

non-settlement, OG 40 

OFAC regulations and, OG 113-OG114 ; 

POP Entry, OG 36, OG 175-OG 176 

prenotifications, OG 66-OG 67 

processing outline, OG 37-OG 38 

processing requirements, OG 36-OG 38 

RCK Entry, OG 35-OG 36, OG 169, OG 171 

reclamations for benefit payments, OG 90 

record retention, OG 32 

reinitiation of returned entries, OG 75, OG 76 

rejected entries, OG 39-OG 40 

relationship with ACH Operator, OG 38-OG 40 

relationship with Originators, OG 8-OG 9, OG 28-OG 30 

requests for RDFI to return an entry, OG 90 

returned/reinitiated entries, notification of change, rejected files, OG39-OG40 

returns, OG 75-OG 78 

reversing entries, OG 91 

rules compliance audit requirements, OG 102-OG 104, OG 118-OG 120, OG 121-OG 122 

rules enforcement, OG 34 

sample agreement between Originators and, OG 13-OG 19 

settlement, OG 40 

settlement agreement with ACH Operator, OG 45 

TEL Entry, OG 36, OG 193-OG 194 

Third-Party Service Providers and, OG 97-OG 101, OG 102-OG 104 

transaction codes and, OG 36-OG 37 

untimely return entries, OG 76-OG 78 

verification of identity of Originators, OG 37 

warranties and indemnifications, OG 3 1-OG 32 

warranties and liabilities, OG 171, OG 175, OG 180, OG 188-OG 189, OG 193 

WEB Entry, OG 36 

XCK Entry, OG 42 
Originating Gateway Operator (OGO), OG 162-OG 168 
Originator obligations and responsibilities 

acknowledgment entries, OG 26, OG 9 1-OG 92 
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ARC Entry, OG 26-OG 27, OG 178-OG 180 

cross-border entries, OG 26 

dishonored returns, OG 75, OG 76-OG 78 

electronic signatures and records, OG 8 

ENR entry, OG 26 

guidelines for similarly authenticated authorizations, OG 21, OG 25 

legal responsibilities, OG 8-OG 25 

NOC responsibilities, OG 72 

OF AC regulations and, OG 1 13 

POP Entry, OG 26, OG 173-OG 175 

prenotifications, OG 27, OG 66-OG 67 

processing requirements and responsibilities, OG 27-OG 30 

RCK Entry, OG 26, OG 169-OG 171 

record retention, OG 8 

reinitiation of returned entries, OG 75, OG 76 

returns, OG 73-OG 74, OG 73-OG 75 

TEL Entry, OG 27, OG 191-OG 193 

transaction codes, OG 27 

WEB Entry, OG 27 
Originators 

about, OG 7-OG 8 

advantages to, OG 7 

agreements/relationship with ODFI, OG 32-OG 34 

definition, OG 4 ; OG 95 

file security, OG28 

issues to be defined in agreement between ODFI and, OG 10-OG 12 

relationship with ODFI, OG 8-OG 9, OG 28-OG 30 

relationship with Receiver, OG 19-OG 23, OG 30 

sample agreement between ODFI and, OG 13-OG 19 

sample credit authorization, OG 24 

sample debit authorization, OG 24 

Third-Party Service Provider agreements, OG 9 8-OG 99 

verification of identity of, OG 28 
Outbound entries. See Originating Gateway Operator 



Payment applications, OG 4-OG 6 

PBR. See Consumer Cross-Border Payment 

Point-of-Purchase Entry (POP) 

about, OG 3, OG 5, OG 173 

authorization requirement, OG 173 

definition, OG 173 

formatting requirements, OG 174-OG 175, OG 175-OG 176 

ineligible debits, OG 23 

legal framework, OG 173 

ODFI agreements, OG 173 

ODFIs and, OG 36, OG 175-OG 176 

Originators and, OG 26, OG 173-OG 175 

RDFIs and, OG 56, OG 61, OG 176-OG 177 

receipt requirements, OG 174 

returns for unauthorized/improper consumer debits, OG 74, OG 85 

returns of, OG 175, OG 176-OG 177 

source documents, OG 173-OG 174 

statement requirements, OG 177 

stop payments, OG 176, OG 177 

warranties and liabilities, OG 175 
Point-of- Sale Entry (POS) 

about, OG 3 
Point of Sale Entry/Shared Network Transaction (POS/SHR), OG 5 
POP. See Point-of-Purchase Entry 
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POS. See Point-of-Sale Entry 

POS/SHR, See Point of Sale Entry/Shared Network Transaction 
PPD. See Prearranged Payment and Deposit Entry 
Prearranged Payment and Deposit Entry (PPD) 

about, OG 5 

Addenda Records, OG 108-OG 109 

credit entries, OG 58 
Preauthorized bill payment, OG 5 
Prenotifications 

definition, OG 66 

ODFIs, OG 66-OG 67 

Originators, OG 27, OG 66-OG 67 

RDFIs, OG 54, OG 67 



R 




RCK. See Re-presented Check Entry 

RDFL See Receiving Depository Financial Institution 

Re-presented Check Entry (RCK) 

about, OG 3, OG 5, OG 168 

collection fees, OG 170 

copy of check, OG 171, OG 172 

eligible items, OG 169 

formatting requirements, OG 171 

ineligible debits, OG 22-OG 23 

legal framework, OG 168-OG 169 

number of presentments, OG 170 

ODFI agreements, OG 169 

ODFIs and, OG 35-OG 36, OG 171 

Originators and, OG 26, OG 169-OG 171 

RDFIs and, OG 56-OG 57, OG 61 

receiptof,OG 172 

restrictive endorsements, OG 170 

retention of copy of item, OG 170, OG 171 

return of, OG 170-QG 171, OG 172 

return reason codes, OG 82-OG 83 

returns for unauthorized/improper consumer debits, OG 74, OG 85 

statement requirements, OG 172 

stop payments, OG 172 
Receiver 

advantages to, OG 7 

definition, OG 4 

OFAC regulations and, OG 1 15 

relationship with Originator, OG 19-OG 23, OG 30 

verification of identity of, OG 192 
Receiving Depository Financial Institution (RDFI) 

acceptance of entries to general ledger and loan accounts, OG 51 

accounting and settlement, OG 58 

ACH credits, OG 57 

ACH debits, OG 57 

ACH payment association membership, OG 49-OG 50 

acknowledgment entries, OG 56, OG 92 

addenda record processing, OG 53-OG 54 

Addenda Records, OG 108 

advantages to, OG 7 

ARC Entry, OG 56, OG 61, OG 1 82-OG 183 

audit requirements, OG 62-OG 63 

authorization revoked vs. stop payment, OG 85-OG 86 

authorizations and agreements, OG 59-OG 60 

automated contested dishonored returns, OG 88 

automated NOC, OG 70 
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automated returns, OG 83 

automatic processing of ACH files, OG51-OG57 

consumer entries, OG 60-OG 61 

contested dishonored returns, OG 75 

corporate entries, OG 5 9-OG 60 

corrected entries, OG 78 

cross-border entries, OG 56 

definition, OG 4, OG 49 

delivery and settlement agreement with ACH Operator, OG 44-OG 45 

delivery of ACH files, OG 51 

DNE Entry, OG 54-OG 56 

electronic signatures and records, OG 59 

exception handling, OG 54 

excused delay, OG 57 

extended return deadlines for unauthorized/improper consumer entries, OG 84 

file editing, OG 52 

file processing, OG 52-OG 53 

file reversals, OG 88-OG 90 

file security, OG 52 

general guidelines for ACH return entries, OG 87 

general ledger accounts, OG 50 

loan accounts, OG 50-OG 51 

manual processing of ACH files, OG 57 

NACHA Operating Rules versus Regulation E, OG 86-OG 87 

NOC responsibilities, OG 68-OG 71 

non-settlement, OG 58 . 

OFAC regulations and, OG 1 14-OG 1 15 

originating contested dishonored returns, OG 77-OG 78, OG 87-OG 88 

output files, OG 46 

POP Entry, OG 56, OG 61, OG 176-OG 177 

posting and funds availability, OG 5 7-OG 58 

PPD credit entries, OG 58 

prenotifications, OG 54, OG 67 \ 

RCK Entry, OG 56-OG 57, OG 61 

reasons for return, OG 78-OG 83 

receipt and processing of files, OG 50-OG 57 

receiving dishonored returns, OG 87 

reclamations for benefit payments, OG 90 

record retention, OG 59 

rejected returns, OG 87 

requests by ODFI to return an entry, OG 90 

responsibilities, OG 49 

return procedure, OG 72-OG 73 

returned and refused NOCs, OG 70-OG 71 

returns, OG 78-OG 88 

reversing entries, OG 91 

rules compliance audit requirements, OG 102, OG 104-OG 105, OG 120-OG 121, OG 122 

rules enforcement and, OG 63 

settlement of return entries, OG 87 

stop payments, OG 79-OG 80, OG 85-OG 86 

TEL Entry, OG 56, OG 194 

Third-Party Service Provider agreements, OG 101 

Third-Party Service Providers and, OG 62-OG 63, OG 101-OG 102, OG 104-OG 105 

timing of returns, OG 83-OG 85 

transaction codes, OG 50-OG 5 1 

unauthorized corporate debits, OG 39-OG 40, OG 59-OG 60, OG 84 

unauthorized/improper consumer debits, OG 60-OG 61 

use of third party to originate NOC, OG 70 

verification of identity of Originators, OG 52 

WEB Entry, OG 56 ■ 

written statement under penalty of perjury, OG 61, OG 64-OG65 
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XCK Entry, OG 54 
Receiving Gateway Operator (RGO), OG 162-OG 168 
Reclamations for benefit payments, OG 90 
Record format specifications. See also Mapping; Sample applications and assumptions; specific records 

basic record sequence for files, OG 134 
Record retention 

ACH Operators, OG 44 

cross-border payments, OG 164 

ODFI,OG32 

Originator obligations and responsibilities, OG 8 

RDFIs and, OG 59 

Third-Party Service Providers, OG 99 
Recurring WEB payments, definition, OG 184 
Refused acknowledgment entries 

ODFIs and, OG 92 

Originators and, OG 92 

RDFIs and, OG 92 
Refused notification of change 

RDFIs and, OG 70-OG 71 

sample applications and assumptions, OG 15 1-OG 152 
Regulation E, versus NACHA Operating Rules, OG 86-OG 87 
Reinitiation of entries, OG 30, OG 39, OG 75, OG 76, OG 179-OG 180 
Rejected entries 

ACH Operators and, OG 47-OG 48 

ODFI and, OG 39-OG 40 

Third-Party Service Providers and, OG 101 
Rejected files, OG 30, OG 39-OG 40 

Report of Possible ACH Rules Violation, OG 63, OG 123-OG 124. 5eea/^ National System of Fines 
Reporting requirements 

blocked accounts, OG 1 16, OG 117 

possible violations, OG 123-OG 124, OG 128-OG 129 

TEL Entry, OG 193 
Representative payee, returns for death of, OG 75 
Request for acknowledgment 

ODFIs and, OG 92 

Originators and, OG 9 1-OG 92 

RDFIs and, OG 92 
Return data, release by ACH Operators, OG 126 
Return entries 

ACH Operator responsibilities, OG 78 

ACH Operators and, OG 78 

ARC Entry, OG 74, OG 85, OG 180, OG 181, OG 182 

cross-border payments, OG 164 

death of beneficiary, representative payee, or account holder, OG 75 

ENR Entry, OG 157-OG 158 

insufficient funds, OG 73 

ODFI requests for RDFI to return an entry, OG 90 

ODFI responsibilities, OG 75-OG 78 

ODFIs and, OG 39-OG 40 

Originator responsibilities, OG 73-OG 75 

Originators and, OG 30 

by other ACH participants and Operators, OG 78 

POP Entry, OG 74, OG 85, OG 175, OG 176-OG 177 

procedure, OG 72-OG 73 

RCK Entry, OG 1 70-OG 171, OG 172 

RDFI responsibilities, OG 78-OG 88 

revocation of authorization, OG 73 

revocation of authorization and, OG 73, OG 85-86 

sample applications and assumptions, OG 142-OG 154 

TEL Entry, OG 193, OG 194 

Third-Party Service Providers and, OG 101 
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unauthorized/improper consumer debits, OG 73-OG 74 

WEB Entry, OG189-OG 190 
Reversals x 

duplicate files, OG88-OG 90 

erroneous entries, OG 91 

erroneous files, OG 88-OG 90 

file reversals, OG 88-OG 89 

Third-Party Service Providers, OG 100 
Revocation of authorization, returns for, OG 73, OG 85-86 
RGO. See Receiving Gateway Operator 
Risk management 

audits of website security, OG 187-OG 188 

fraudulent transaction detection systems, OG 186 

routing number verification, OG 186, OG 192 

security of Internet session, OG 186-187 

TEL Entry, OG192-OG 193 

verification of identity of receiver, OG 192 

WEB Entry, OG 185-OG 188 , 
Rules compliance audit requirements. See Audit controls and compliance 
Rules enforcement, OG 1 22 

ACH Rules Enforcement Panel, OG 126-OG 127 

ODFIs,OG34 

Originator/ODFI agreements, OG 29 

RDFIs and, OG 63 



Sample applications and assumptions, OG 135 

ACH file from ODFI to ACH Operator, OG 135-OG 142 

contested dishonored return entries, OG 152-OG 154 

dishonored return entries, OG 148-OG 151 

refused NOCs, OG 151-OG 152 

returns and NOC entries, OG 142-OG 154 
Settlement and accountability 

about, OG 29-OG 30 

ACH Operators and, OG 44, OG 45, OG 48, OG 49 

cross-border payments, OG 163, OG 164 

DFI delivery and settlement agreement with ACH Operator, OG 44-OG 45 

ODFI non-settlement, OG 40 

ODFI settlement, OG 40 

ODFI settlement agreement with ACH Operator, OG 45 

RDFI delivery and settlement agreement with ACH Operator, OG 44-OG 45 

RDFI non-settlement, OG 58 

RDFI settlement of return entries, OG 87 

RDFIs and, OG 58 
SHR. See Point of Sale Entry/Shared Network Transaction 
Single-entry WEB payments, definition, OG 1 1 84 
Source documents 

ARC Entry, OG 180, OG 182-OG 183 

POPEntry,OG 173-OG 174 
Special Committees on Paperless Entries (SCOPE), OG2 
Standard Entry Class Code, OG 4-OG 6 
Statement requirements 

ARC Entry, OG 183 

POP Entry, OG 177 

RCKEntry,OG 172 
Stop payments 

ARC Entry, OG 180, OG 181, OG 182 

POP Entry, OG 176, OG 177 

RCK Entry, OG 172 

returns for, OG 85-OG 86 
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TEL Entry, OG 194 

WEB Entry, OG189,OG190 




TEL. See Telephone-Initiated Entry 
Telephone-Initiated Entry (TEL) 

about, OG 3, OG 5-OG 6, OG 190-OG 191 

authorization requirements, OG 1 9 1 -OG 192 

initiating, OG 190 

legal framework, OG 190 

ODFI agreements, OG 191 

ODFIs and, OG 36, OG 193-OG 194 

Originators and, OG 27, OG 191-OG 193 

RDFIsand,OG57,OG194 

reporting requirements, OG 193-OG 194 

return of entries, OG 193, OG 194 

risk concerns, OG 190-OG 191 

risk management, OG 192-OG 193 

routing number verification, OG 192 

stop payments, OG 1 94 

verification of identity of receiver, OG 1 92 

warranties and liabilities, OG 193 
Testing procedures, OG 29 
Third-Party Senders 

agreements, OG 98 

definition, OG 95-OG 96 
Third-Party Service Providers 

about, OG 94-OG 96 

agreements, OG 34-OG 35, OG 98-OG 99, OG 101 

audit requirements, OG 40-OG 42, OG 62-OG 63 

audit trail and, OG 100 

definition, OG 4, OG 95 

electronic signatures and records, OG 99 

obligations, OG 100 

ODFIs and, OG 34-OG 35, OG 97-OG 101, OG 102-OG 104 

OF AC regulations and, OG 1 1 5 

to originate ENR, OG 157 

to originate RDFI NOC, OG 70 

origination of ACH entries, OG 97-OG 101 

processing functions, OG 101-OG 102 

RDFI use to originate NOG, OG 70 

RDFIs and, OG 62-OG 63, OG 101-OG 102, OG 104-OG 105 

receiving ACH entries, OG 101-OG 102 

record retention, OG 99 

returns/NOCs/rejected entries, OG 101 

reversal/erroneous entries, OG 100 

role of, OG 95-OG 96 

rules compliance audit requirements, OG 102-OG 105, OG 117 

as Third-Party Sender, OG 96 

warranties/indemnifications, OG 99-OG 100, OG 1.01 
Transaction codes 

ODFIand,OG36-OG37 

Originators and, OG 27 
TRC/TRX. See Truncated Entries 
Truncated Entries (TRC/TRX), about, OG 6 
TRX. See Truncated Entries 
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Unauthorized corporate entries, OG 39-OG 40, OG 59-OG 60, OG 84 

Unauthorized/improper consumer debits, OG 84-OG 85 ^.\^ An np .„ _,, _ „ „ nr 74 nr o d nrT 
Unauthorized/improper consumer entries, OG 22-OG 23, OG 39-OG 40, OG 60-OG 61, OG 73-OG 74, OG 84-OG 
85 



Verification of identity 
of Originators, OG28 
of Originators, ODFIs, OG 37 
of Originators, RDFIs, OG 52 

w 

Warranties and liabilities 

Gateway Operators, OG 164 

ODFI limitations on warranties, OG 32 .■ . ; . 

ODFIs, OG 31-OG 32, OG 171, OG 175, OG 180, OG 188-OG 189, OG 193 

Third-Party Service Providers, OG 99-OG 100, OG 101 
WEB Entry. See Internet-Initiated Entry (WEB) 

x 

X12 Data Segment Requirement, OG 109 
XCK. See Destroyed Check Entry (XCK) 

z 

Zero Dollar entries, OG 23 
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REGIONAL ACH PAYMENTS 
ASSOCIATION RULES 

Regional ACH payments association rules apply to 
intraregional transactions only. Local rules may be 
revised, updated, enacted, or removed at any time. 

The following payments associations have adopted their 
own rules for intraregional transactions. To obtain a copy 
of their rules, contact the association at the number listed 
in this section. 

JP Morgan Chase 
Electronic Payments Network 
New England ACH Association 
Western Payments Alliance 

The following payments associations have adopted the 
NACHA Operating Rules as the standard for all ACH 
transactions: 

ABN AMRO Bank 

American Express Centurion Bank 

Alabama ACH Association 

Bank of America 

BB&T 

Capital One Services, Inc. 

Citibank, N.A. 

Commerce Bank 

Discover Bank 

EastPay, Inc. 

Fort Knox National Company 

GACHA 

Key Bank 

Mellon Financial Corporation 

MACHA -The Mid- Atlantic Payments 

Association 
Mid America Payment Exchange 
National City Corporation 
Northwest Clearing House Association 
PNC Bank 

Payments Central, Inc. 
Payments Resource One 
SHAZAM,Inc. 

South Carolina ACH Association 
Southern Financial Exchange 
SWACHA - The Electronic Payments 

Resource™ 
TCF National Bank 
Tennessee ACH Association 
The Payments Authority, Inc. 
U.S. Bank 

Upper Midwest ACH Association 
Wachovia Bank, N.A. 
Wells Fargo 
WACHA - The Premier Payments Resource 



PAYMENTS ASSOCIATIONS & 
DIRECT FINANCIAL 
INSTITUTION MEMBERS 

Following are contacts for NACHA's member 
associations/direct financial institution members: 

ALABAMA ACH ASSOCIATION 

Pamela T. Rodriguez, AAP, CIA, CISA 

Executive Director 

2 Riverchase Office Plaza 

Suite 111 

Birmingham, AL 35244 

Phone:(205)733-0006 

Fax:(205)733-0606 

EMail: pam@alacha.org 



EASTPAY, INC. 

Richmond Office 

Norman K. Robinson, AAP CTP 

President 

7400 Beaufont Springs Drive, Suite 405 

Richmond, VA 23225 

Phone: (804) 644-1642 xlOO 

Fax:(804)648-5254 

EMail: nrobinson@eastpay.org 

Florida Office 

Gina Carter, AAP 

Director of Education 

901 N. Lake Destiny Rd., Suite 130 

Maitland,FL 32751 

Phone:(407)661-5825 

Fax:(407)661-5821 

EMail: gcarter@eastpay.org 

North Carolina Office 

GaryB.Nesbitt, AAP 

SVP, Administration & Training 

425-A South Sharon Amity Road 

Charlotte, NC 28211 

Phone:(704)366-7292 

Fax:(704)366-7557 

EMail: gnesbitt@eastpay.org 
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ELECTRONIC PAYMENTS NETWORK 



NEACH 



Main Office 

Frank Sardina, AAP 

Vice President, Products & Services 

100 Broad Street 

New York, NY 10004 

Phone:(201)319-5402 

Fax:(201)319-5491 

EMail: frank.sardina@epaynetwork.com 

Midwest Office 

Darlene Ruffin, AAP 

Senior Trainer 

230 S. LaSalle St., Suite 700 

Chicago, IL 60604 

Phone:(312)913-2595 

Fax:(312)913-2599 

Email: darlene.ruffm@epaynetwork.com 

GACHA 

Terri Pelle Sands, AAP 

President 

2410 Paces Ferry Road 

400 Paces Summit 

Atlanta, GA 30339 

Phone:(770)805-2371 

Fax:(770)805-2375 

EMail: tsands@gacha.org '...'.... 



MACHA - THE MID- ATLANTIC PAYMENTS 
ASSOCIATION 



William M. Lynn, Jr. 

President 

1344 Ashton Road 

Suite 202 

Hanover, MD 21076 

Phone:(410)859-0090 

Fax:(410)859-3452 

EMail: machawml@aol.com 



MID-AMERICA PAYMENT EXCHANGE 

Ann-Marie B artels, AAP 

President & CEO 

1 12 West 9th Street, Suite 700 

Kansas City, MO 64105 

Phone:(816)474-5630 

Fax:(816)471-7665 

EMail: ann-marie@mpx.org 



Linda O'Hara 

President 

14 Summer Street, 4th Floor 

Maiden, MA 02 148 

Phone:(781)321-1011 

Fax:(781)338-9627 

EMail: ohara@paymentsystems.org 

NORTHWEST CLEARING HOUSE 
ASSOCIATION 

William Bley, AAP 
President & CEO 

1800 NW Market Street 

Suite 201 

Seattle, WA 98107 

Phone:(206)622-7846 

Fax:(206)622-3197 

EMail: bley@nwcha.org 

PAYMENTS CENTRAL 



Gerald P. Woessner, AAP 

President & CEO 

3380 Tremont Road 

2ndFloor 

Columbus, OH 43221-21 12 

Phone:(614)457-2204 

Fax:(614)457-4824 

EMail: jerry@paymentscentral.org 

PAYMENTS RESOURCE ONE 

Holly Merrill, AAP 

President & CEO 

4000 N. Central Ave. 

Suite 700 

Phoenix, AZ 85012-3503 

Phone:(602)340-1600 

Fax:(602)340-1488 

E-mail: hmerrill@lpro.org 

General E-mail: mail@lpro.org 

SHAZAM,INC. 

Diana Kern, AAP 

Senior Trainer 

6700 Pioneer Parkway 

Johnston, IA 501 31 

Phone: (800) 383-8000, ext 2933 

Fax:(515)248-5828 

E-mail: dkern@shazam.net 
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SOUTH CAROLINA ACH ASSOCIATION 

Allen Young, AAP 

Executive Director 

7440 Broad River Road 

Irmo, SC 29063 

Phone:(803)732-1579 

Fax:(803)732-4268 

EMail: socacha@logicsouth.com 

SOUTHERN FINANCIAL EXCHANGE 

Linda M. Bradfield, AAP 
President & CEO 

1340 Poydras Street, Suite 2010 
New Orleans, LA 70112-1221 
Phone: (504) 525-6779x24 
Fax:(504)525-1693 
EMail: lbradfield@sfe.org 

SWACHA -THE ELECTRONIC PAYMENTS 
RESOURCE 



Dennis Simmons, AAP 

President & CEO 

1 999 Bryan Street, Suite 1 5 00 

Dallas, TX 75201 

Phone:(214)953-4720 

Fax:(214)720-0029 

EMail: dennis.simmons@swacha.org 



TENNESSEE ACH ASSOCIATION 

Donna S. Ashworth, AAP 

Executive Director 

6080 Dividing Ridge Road 

Goodlettsville, TN 37072 

Phone:(615)859-4188 

Fax:(615)859-3719 

EMail: donna@tacha.org 



THE PAYMENTS AUTHORITY, INC. 

Amy L. Smith, AAP, CAE 

President & CEO 

1 301 West Long Lake Road 

Suite360 

Troy, MI 48098-6349 

Phone:(248)952-5800 

Fax:(248)952-5820 

EMail: asmith@thepaymentsauthority.org 



UPPER MIDWEST ACH ASSOCIATION 

Fred Laing, II, AAP CCM 

President 

7100 Northland Circle 

Suite 212 

Brooklyn Park, MN 55428 

Phone:(763)549-7000 

Fax:(763)549-7004 

EMail: tredl@umacha.org 

WACHA - THE PREMIER PAYMENTS 
RESOURCE 

MaryM. Gilmeister, AAP 

President 

W177 N9886 Rivercrest Drive, Suite 112 

Germantown, WI 53022 

Phone:(800)453-1843 

EMail: mgilmeister@wacha.org 

WESTERN PAYMENTS ALLIANCE 

Peter Yeatrakas, AAP 

President & CEO 

100 Bush Street, Suite 400 

San Francisco, CA 94104 

Phone:(415)373-1185 

Fax:(415)433-1370 

EMail: pyeatrakas@wespay.org 

DIRECT FINANCIAL INSTITUTION MEMBERS 

ABNAMROBANK 

Mary Miles-Carlson 

Senior Vice President 

540 West Madison, Suite 902 

Chicago, IL 60606 

Phone:(312)904-7296 

Fax:(312)904-8353 

EMail: mary.miles-carlson@abnamroxom 

AMERICAN EXPRESS CENTURION BANK 

GregD. Sterner 

Director 

Operations & Security Officer 

4315S.2700W. 

Salt Lake City, Utah 84184-0216 

Phone:(801)945-2023 

Fax:(801)945-2081 

Email: Greg.D.Sterner@aexp.com 
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BANK OF AMERICA 

Eileen Poss 

Sr. VP Industry Leadership 

600 Peachtree St. NE 

12th Floor 

Atlanta, GA 30308 

Phone:(404)607-5733 

Fax:(214)290-8363 

EMail: eileen.m.poss@bankofamerica.com 

BB&T 

Marshall E. Tyner, AAP, CCM 
SVP, Payment Systems Strategist 
2501 Wooten Blvd., MC: 100-99-13-15 
Wilson, NC 27894 
Phone:(252)246-3391 
Fax:(252)246-2469 
EMail: wtyner@bbandt.com 

CAPITAL ONE SERVICES, INC. 

Stephen Winston, AAP 

Treasury Operations Manager 

140 East Shore Drive 

Attention: 12017-0135 

Glen Allen, VA 23059 

Phone:(804)290-6714 

Fax:(804)290-6857 

EMail: stephen.winston@capitalone.com 



.CITIBANK N.A.- 
Maria. Mandler 
Managing Director 
388 Greenwich St. 25th Fl. 
New York, NY 10013 
Phone:(212)816-5867 
Fax:(212)816-6328 
E-Mail: maria.mandler@citigroup.com 

COMMERCE BANK 

Richard W. Burke, Jr., CCM 
Senior Vice President 
6000 Atrium Way 
Mount Laurel, NJ 08054 
Phone:(856)533-6565 
Fax:(856)470-1288 
EMail: rburke@yesbank.com 



DISCOVER BANK : 

Mike J. Sanchez, AAP 

Sr. Associate - Bank Operations 

12 Read's Way 

New Castle, DE 19720 

Phone:(302)323-7324 

Fax:(302)323-7171 

EMail: mikesanchez@discoverfinancial.com 



FORT KNOX NATIONAL COMPANY 

James R. Fugitte 

President 

400RingRd. 

Elizabethtown, KY 42701 

Phone: (270) 769-2223 x2200 

Fax:(270)769-6493 

EMail: jimrf@fknc,com 

JPMORGAN CHASE 

Marcie Haitema 

Senior VP & Operations Exec. 

10430 Highland Manor Drive 

Building One, 2nd Floor 

Tampa, FL 33610 

Phone:(813)432-3680 

Fax:(813)432-3816 

EMail: marcie.j.haitema@chase.com 

KEYBANK 

Annette Hazapis 

Senior Vice President 

2025 Ontario Street 

OH-0 1-00-0400 

Cleveland, OH 441 15-1022 

Phone:(216)689-7216 

Fax:(216)689-9551 

EMail: annette_hazapis@keybank.com 

MELLON FINANCIAL CORPORATION 

Marsha A. Bianco, AAP 

Vice President, EFT Operations 

Mellon Client Service Center - Suite 960 

500 Ross Street 

Pittsburgh, PA 15262-0001 

Phone:(412)236-1319 

Fax:(412)234-0619 

EMail: bianco.ma@mellon.com 



PA YMENTS ASSOCIA TIONS 4 



2005 ACH RULES 



PAYMENTS ASSOCIATIONS 



NATIONAL CITY CORPORATION 

Mary Ann Francis 

Senior Vice President 

1900 East 9th Street - Locator 01-2139 

Cleveland, OH 441 14-3484 

Phone:(216)222-9395 

Fax:(216)222-8192 

EMail: maryann. francis@nationalcity.com 

PNC BANK 

Phil Ahwesh 

Vice President 

620 Liberty Avenue, Two PNC Plaza, 32nd Fl. 

MS:P2-PTPP-32-l 

Pittsburgh, PA 15265 

Phone:(412)762-0869 

Fax:(412)705-2584 

EMail: philip.ahwesh@pnc.com 

TCF NATIONAL BANK 
Wallace A. Fudold 
Executive Vice President 
200 East Lake Street 
Wayzata,MN 55391 
Phone:(952)475-7946 
Fax:(952)475-7937 
EMail: wrudold@tcfbank.com 



WELLS FARGO 

Kris Koppelman, AAP 

Vice President, Product Management 

Sixth & Marquette 

MACN9305-073 

Minneapolis, MN 55479 

Phone:(612)316-3227 

Fax: (612) 466-5046 




U.S. BANK 

NadiaL. Kozak 

Vice President, Sr. ACH Product Manager 

US Bancorp Center - 800 Nicollet Mall 

MC: BC-MN-H20P 

Minneapolis, MN 55402-7020 

Phone:(612)303-7335 

Fax:(612)303-7588 

EMail: nadia.kozak@usbank.com 

WACHOVIA BANK, N.A. 

Janet C. Boyst 

SVP/Group Executive 

401 Linden Street 

MC:NC6761 

Winston-Salem, NC 27101 

Phone:(336)735-2531 

Fax:(336)735-0916 

EMail: janet.boyst@wachovia.com 
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Federal Reserve Operating Circulars, including the ACH 
Operating Circular, can be referenced atwww.frbservices.org by 
selecting the appropriate Service Information category. 
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FEDERAL RESERVE BANK 
OPERATING CIRCULAR NO. 4 

Effective August 1, 2004 

AUTOMATED CLEARING HOUSE ITEMS 
CONTENTS 
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3. Sending Credit And Debit Items 

4 . Security Procedures 
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9 Designation Of Settlement Account 
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15. Disputed Returns 

16. Advices Of Credit And Debit; Reporting Of Errors 

17. Records 

18. Fees 

19. Non-Value Messages 

20. Additional Informational Services 

21. Reserve Bank Liability; Item Other Than Credit Item 
Subject To Article 4 A 

22. Reserve Bank Liability; Credit Item Subject To 
Article4A 
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25. Right To Amend 

Appendix A ACH Security Procedures 
Appendix Al ACH Security Procedure Agreement 
Appendix B ACH Items Time Schedule 

Appendix C Prefunding of ACH Credit Originations 

by Sending or Correspondent Bank 
AppendixD Government ACH Items 



1.0 GENERAL 

1 . 1 This operating circular, its appendices and our time 
and fee schedules (collectively "Circular") govern 
the clearing and settlement of commercial 
automated clearing house (ACH) credit and debit 
items (including credit items subject to Article 4 A) 
by the Federal Reserve Banks, sending banks, and 
receiving banks. Government ACH items are 
governed by Appendix D to this Circular. Each 
Reserve Bank has issued a Circular identical to this 
one. 

1 .2 This Circular is issued pursuant to Sections 4, 1 1 A, 
13, 16 and 19 of the Federal Reserve Act and 
related statutes. With respect to items other than 
credit items subject to Article 4 A, this Circular is 
binding on a sending bank that sends items to a 
Reserve Bank, a receiving bank that receives items 
from a Reserve Bank, an account holder that has 
agreed to settle for items under this Circular, and 
another party interested in an item that agrees to 
this Circular or that is otherwise bound by it. 

1 .3 The provisions of Article 4 A of the Uniform 
Commercial Code are incorporated in this Circular 
with respect to credit items subject to Article 4A. 
In the event of inconsistency between the 
provisions of this Circular and Article 4 A with 
respect to such a credit item, the provisions of this 
Circular shall control. As regards credit items 
subject to Article 4A, this Circular is an operating 
circular as referred to in Section 4 A- 1 07, and is not 
a funds transfer system r u 1 e a s 
defined in Article 4 A. Nevertheless, this Circular 
governs the rights and obligations of parties to a 
funds transfer subject to Article 4 A to the same 
extent as if this Circular were a funds transfer 
system rule. Under Article 4A,this Circular is 
binding on parties to an item besides the sending 
and receiving banks if the parties have notice that 
the Reserve Banks' funds transfer systemmight 
he used for the transaction and that this Circular 
will apply, unless those other parties have agreed 
otherwise. 

1.4 The following rules and agreements, as amended 
from time to time, are incorporated in this 
Circular as applicable ACH rules with respect to 
items, regardless of whether the sending bank or 
receiving bank is a member of an ACH association: 




(a) 



The Operating Rules of the National 
Automated Clearing House Association 
(NACHA), unless other rules apply under 
subparagraph (b). 



(b) The Operating Rules of regional ACH 
Associations that are members of NACHA, 
to the extent such rules (i) bind both the 
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sending bank and the receiving bank or (ii) 
in the case of a transaction involving a 
nonmember(s) of an ACH association, 
generally apply to transactions within the 
region where the sending bank and 
receiving bank are located. 

Not incorporated in this Circular as applicable 
ACH rules are provisions that: 

(a) are in conflict with applicable law; 

(b) with respect to credit items subject to 
Article 4A, are in conflict with provisions of 
Article 4A that may not be varied; 

(c) limit the applicability of the ACH rules to 
members of an ACH association; 

(d) require dues or fees (other than a reasonable 
fee for copies of the ACH rules); 

(e) require execution of agreements by 
participating banks (such as settlement or 
indemnity agreements); 

(f) govern arbitration of disputes among 
participants; or 

(g) provide for payment of legal expenses to an 
ACH association in suits 

against the association. 

This Circular does not affect the applicability of 
these provisions to members of the ACH 
association. This Circular preempts or supersedes 
the applicable ACH rules or other arrangements 
among parties to ACH items only to the extent that 
the provisions of those arrangements are 
inconsistent with this Circular. 

2.0 DEFINITIONS 

2. 1 As used in this Circular: 

(a) account means an account with reserve 
and/or clearing balances on the books of a 
Federal Reserve Bank. A sub-account is an 
information record of a subset of 
transactions that affect an account, and is 
not a separate account. 

(b) actually and finally collected funds means 
cash or any other form on payment that is, 
or has become, final and irrevocable. 

(c) Aclministrative Reserve Bank means the 
Reserve Bank in whose District an entity is 
located, as determined under the procedure 
described in 12 CFR 204.3(b)(2), even if 
the entity is not otherwise subject to that 
section. 

(d) applicable ACH rules means the rules and 
agreements designated in this Circular as 
applicable to designated ACH transactions. 
See paragraph 1.4. 



(e) Article 4A means Article 4A of the Uniform 
Commercial Code as set forth in Appendix 
B of Regulation J, 12 CFR Part 210, 
Subpart B. It includes provisions of Article 
1 referred to in Article 4A as approved from 
time to time by the National Conference of 
Commissioners on Uniform State Laws and 
the American Law Institute; 

(f) as of adjustment means a debit or a credit, 
for reserve or clearing balance maintenance 
purposes only, applied to the account of a 
sending or receiving bank in lieu of an 
interest charge or payment. 

(g) automated clearing house or ACH means a 
facility that clears debit and credit items for 
banks. 

(h) bank means (i) a depository institution as 
defined in Section 19(b) of the Federal 
Reserve Act (12 US.C. 461(b)); (ii) a 
branch or agency of a foreign bank 
maintaining reserves under Section 7 of the 
International Banking Act of 1978 (12 
U.S.C 347d, 3105); (hi) a department, 
agency, instrumentality, independent 
establishment, or office of the United 
States, or a wholly owned or controlled 
Government corporation; or (iv) another 
entity for which a Reserve B a n k 
directly provides ACH services. 

(i) banking day means the part of a day during 
which a Reserve Bank, account holder, 
sending bank or receiving bank is open for 
the receipt, processing or transmission of 
items. See Appendix B for the Reserve 
Banks' ACH banking day. With respect to 
a credit item subject to Article 4A, banking 
day means a funds transfer business day. 

(j) credit item means an item a sending bank 
sends to a Reserve Bank for debit to the 
sending bank's settlement account and for 
credit to a receiving 

bank's settlement account. Unless otherwise 
expressly stated, the term includes a credit 
item subject to Article 4A. 

(k) credit item subject to Article 4A means a 
credit item that is a payment order as 
defined in Article 4 A. The term does not 
include an ACH credit transaction any part 
of which is governed by the Electronic Fund 
Transfer Act, as amended, an inter-Reserve 
Bank settlement wire, or a non-dollar 
message such as a zero dollar return, 
prenotification, notification of change, or 
automated enrollment. 
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(1) debit item means an item a sending bank 
sends to a Reserve Bank for credit to the 
sending bank's settlement account and for 
debit to a receiving 

bank's settlement account. 



(m) effective date means the date for settlement 
that a sending bank specifies in an item. See 
paragraph8. 

(n) effective date window means the minimum 
and maximum period of days after the 
Reserve Bank processing date within which 
the effective date must fall to receive 
desired settlement. See paragraph 8. 

(o) item means an instruction for the payment 
of money that is handled by a Reserve Bank 
for processing or settlement under its ACH 
Circular. Item does not include: (i) an item 
as defined in Section 210.2 of Regulation 
J that is handled under Subpart A governing 
the collection of checks and other items; (ii) 
a payment order as defined in Section 
210.26 of Regulation J that is handled under 
SubpartB governing funds transfers through 
the Fedwire® 1 funds transfer system; (iii) a 
payment instruction subject to 3 1 CFR Parts 
210 or 370, or other Treasury Department 
regulations governing Federal payments by 
the ACH method; or (iv) a wire transfer of 
securities by a Reserve Bank. Unless the 
context otherwise requires, the term 
includes both a credit item and a debit item. 

(p) receiving bank means a bank designated in 
an item to receive the item from a Reserve 
Bank/ With respect to a credit item subject 
to Article 4A^ the term receiving bank may 
include a beneficiary as defined in Article 
4A. ■;■'■■':■;':'■■':■'■■'■'■■.'■■.■■'■. 

(q) sending bank means a bank designated in an 
item as sending the item to a Reserve Bank. 

(r) servicing Reserve Bank means the Reserve 
Bank which is a sending or receiving bank's 
primary contact for communications relating 
to ACH items. The servicing Reserve Bank 
is usually the bank's Administrative Reserve 
Bank. 

(s) settlement account means the account at a 
Reserve Bank that the sending bank or 
receiving bank maintains, or a 
correspondent bank's account that the 



Fedwire is a registered service mark of the Federal 
Reserve Banks. 



sending bank or receiving bank uses to 
settle items. 

(t) settlement date means the date for 
settlement of an item as provided in this 
Circular. 

(u) unless the context otherwise requires, terms 
not defined in this section but defined in the 
applicable ACH rules have the meanings 
given in such rules. 



3.0 SENDING CREDIT AND DEBIT ITEMS 

3.1 A sending bank that maintains or uses a settlement 
account at a Reserve Bank may send an item to any 
Reserve Bank, provided the receiving bank 
maintains or uses a settlement account for ACH 
items at a Reserve Bank. A sending bank may 
designate a sending point or ACH operator (other 
than a Reserve Bank) as its agent to send items to 
a Reserve Bank. The sending point or ACH 
operator (other than a Reserve Bank) is not a 
sender or receiving bank as defined in Article 4A, 
or a party to the item, in acting as agent of a 
sending bank. 

3.2 For purposes of this Circular and Article 4A, the 
sending bank is deemed to have sent an item to its 
Administrative Reserve Bank, regardless of which 
Reserve Bank holds the sending bank's settlement 
account, maintains its electronic connection or 
receives the item. No Reserve Bank, other than the 
sending bank's Administrative Reserve Bank and 
the receiving bank's Administrative Reserve Bank, 
is a party to the item or a sender or receiving bank 
under Article 4 A. 

3.3 The sending bank's or receiving bank's 
Administrative Reserve Bank may instruct another 
Reserve Bank concerning the other Reserve Bank's 
handling of or settlement for an ACH item for 
purposes of managing the Administrative Reserve 
Bank's risk. 

3.4 An item must be in the media the Reserve Banks 
prescribe and in the format prescribed by the 
applicable ACH rules. 

3.5 If a sending bank transmits an ACH file to the 
Reserve Bank in a form that requires the sending 
bank to take additional steps to release the file for 
processing, the file will be considered to have been 
sent to the Reserve Bank at the time the sending 
bank has completed all steps that are necessary to 
release the file for processing by the FedACH 
application. Files consisting of ACH items that are 
transmitted to the Reserve Bank's systems by a 
bank must be released for processing prior to the 
end of day cutoff, or the files will be deleted. The 
responsibility for releasing such a file rests 
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exclusively upon the sending bank. The Reserve 
Bank assumes no duty to inform a bank that the 
bank has transmitted an ACH file but has not 
released that file for processing. 

4.0 SECURITY PROCEDURES 

4.1 The security procedures a Reserve Bank offers to 
verify the authenticity of the source of an item are 
described in Appendix A of this Circular. Before 
sending an item to a Reserve Bank, a sending bank 
must execute an agreement with its servicing 
Reserve Bank in the form of Appendix AT, copies 
of which are available from the Reserve Banks. If 
a sending bank sends an item through an agent, the 
agent must also execute an agreement in the same 
form. A sending bank is deemed to agree to any 
security procedure used in sending an item to a 
Reserve Bank. 

4.2 Each sending and receiving bank shall prevent any 
disclosure, except on a "need to know" basis, of 
any aspects of the security procedures agreed to by 
it with its servicing Reserve Bank. The sending or 
receiving bank shall notify its servicing Reserve 
Bank immediately if the confidentiality of these 
security proce dur es is 
compromised, and shall act to prevent the security 
procedure from being further 
compromised. 

5.0 ■.'■. SENDING BANK'S AGREEMENTS 

5.1 By sending an item to a Reserve Barik, the sending 
bank: 



(a) agrees to comply with the applicable ACH 
rules and agrees that those rules govern the 
relationships among the sending bank, the 
receiving bank and other parties interested 
in the item and covered by those 
rules; 



(b) authorizes the Reserve Banks to process the 
item in accordance with this Circular; 



(c) authorizes the Reserve Bank holding the 
sending bank's settlement account to debit 
the amount of a credit item, or credit the 
amount of a debit item, to the sending 
bank's settlement account on the settlement 
date; and 

(d) agrees to indemnify each Reserve Bank 
processing or settling for the item for any 
loss or expense (including attorneys fees 
and expenses of litigation) incurred by the 
Reserve Bank as a result of any action taken 
with respect to the item by the Reserve 
Bank in accordance with its Circular. 



5.2 The agreements, authorizations and indemnity in 
paragraph 5.1 do not limit any other agreement, 
authorization or indemnity, not inconsistent with 
paragraph 5.1, made by a sending bank to a 
receiving bank, a Reserve Bank or another person. 

5.3 The Administrative Reserve Bank of a (sending or 
correspondent) bank that settles for credit item 
originations may require the bank to prefiind in 
accordance with Appendix C credit item 
originations that settle through thebank's account, 
if the Administrative Reserve Bank has determined 
to monitor the bank's account in real time. If credit 
item originations are not prefunded when required, 
they may be rejected. 2 In the event of prefunding, 
a Reserve Bank will substitute itself for the sending 
or correspondent bank's settlement obligation with 
respect to the credit items, and Appendix C shall 
supersede other provisions of this Circular that are 
inconsistent with Appendix C. 



6.0 PROCESSING OF ITEMS 

6.1 The Reserve Banks process items in accordance 
with the applicable ACH rules and this Circular. A 
Reserve Bank may reject, or may impose 
conditions to its processing of, any item for any 
reason. A Reserve Bank will not act on instructions 
in an item other than information required by 
format specifications in applicable ACH rules. If a 
Reserve Bank notifies a sending bank of the receipt 
of a suspected duplicate file or any other problem, 
the Reserve Bank will not process the file without 
approval by the sending bank or its agent. Except 
as expressly provided in this Circular, a Reserve 
Bank does not have or assume any responsibility 
for a sending or receiving bank's, or ACH 
operator's (other than a Reserve Bank's), 
compliance with applicable ACH rules. A Reserve 
Bank may record by audio recording device any 
telephone call relating to an item. 



6.2 The Reserve Banks send an acknowledgment to the 
sending bank that aReserve Bank has received 
ACH files by electronic transmission and has 



In certain circumstances, the Reserve Bank may be 
unable to determine whether a sending bank is able to prefund its 
credit item originations. In such circumstances prefunding can not 
occur, and any credit item originations settling to the account of a 
mon itored bank may not be processed until the Reserve Bank is able 
to determine whether the sending bank has sufficient funds available 
in the designated settlement account. If the Reserve Bank is unable to 
obtain such information prior to the end of day cutoff, any files that 
have been pended for the reasons described in this footnote may be 
rejected. The Reserve Bank is not liable for any loss or damage that 
results from delays in processing credit item originations, or from the 
rejection of credit items, settling to the account of a monitored 
institution in these circumstances. 
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performed limited processing of the files, as 
provided in applicable ACH rules. An 
acknowledgment does not mean that a Reserve 
Bank has accepted, and will not reject, the items 
contained in the files. The sending bank is 
responsible for verifying the information in the 
acknowledgment and notifying the servicing 
Reserve Bank immediately of any discre^^ 
and for notifying the servicing Reserve Bank 
promptly of nonreceipt of an acknowledgment. 
See paragraph 19. 

6 3 A sending bank must designate the receiving bank 
for an item by routing number. A Reserve Bank is 
not responsible for the accuracy of a routing 
number contained in and/or verbally supplied from 
a publication, list or automated file issued or 
maintained by a Reserve Bank if the routing 
number becomes inaccurate after the effective date 
of the publication, list or file. A Reserve Bank may 
process an item on the basis of a routing number of 
a receiving bank appearing in any form on the item 
when received. A Reserve Bank is not responsible 
for any loss or delay resulting from acting on the 
number, whether or not the number is consistent 
with any other designation of the receiving bank on 
the item, if the Reserve Bank does not know of the 
inconsistency in designation. For purposes of 
Article 4A, an identifying number of a branch of a 
domestic bank is deemed to be the identifying 
number of the bank. 

CROSS-BORDER PAYMENTS 

6.4 The Reserve Banks process certain cross-border 
ACH items in accordance with this Circular, 
agreements between a Reserve Bank gateway 
operator and a foreign gateway operator, and the 
International ACH Service Manual issued by the 
Reserve Banks as applicable to specified foreign 
countries, as amended from time to time. These 
rules, agreements, and guidebooks generally do not 
supersede the laws and rules that apply to the 
handling of items in foreign payment systems. The 
application of foreign payment system rules to a 

cross-border ACH item may produce outcomes 
different from the outcomes that would result from 
handling of the same item under domestic rules. 
For example, the time for return of cross-border 
items may be different; returned items may not be 
able to be dishonored; cross-border items may not 
be reversible; prenotes, and items to be settled on 
a foreign holiday, may not be acceptable; the 
receiver may not receive credit on the settlement 
date; and special fees may apply. Sending and 
receiving banks are responsible for understanding 
the rules applicable to cross-border payments in a 
foreign country, and the limitations on types of 
cross-border payment transactions that are 
accepted by Reserve Banks. 



6.5 



6.6 



6.7 



6.8 



Notwithstanding paragraph 21.1 (c) of this Circular, 
a Reserve Bank acting as a gateway operator for an 
outbound cross-border item warrants to the sending 
bank only that it has processed and edited the item 
in a manner that is in compliance with the 
applicable agreement between the Reserve Bank 
gateway operator and the foreign gateway operator, 

and with this Circular. 

Notwithstanding paragraph 2 1.1(c) of this Circular, 
a Reserve Bank acting as gateway operator for an 
inbound cross-border item warrants to the 
receiving bank only that the item (a) is in 
accordance with an authorization of the receiver, 
and (b) is in compliance with the requirements of 
this Circular. 

A Reserve Bank gateway operator's liability for 
breach of warranty under paragraphs 6.5 and 6.6 is 
limited to the amount of the item, interest and 
expenses, and does not include damages that are 
attributable to the consequences of the breach, 
even if the consequences were foreseeable at the 
time of the breach. 

Under agreements between a Reserve Bank 
gateway operator and a foreign gateway operator, 
the sending bank bears all risk of exchange rate 
fluctuation during the processing of a cross-border 
item. A Reserve Bank assumes no liability to a 
sending bank or other person with respect to a 
return of a crossborder item whether or not it is 
returned in accordance with the payments system 
rules of the receiving country. Sending and 
receiving banks are responsible for complying with 
applicable Office of Foreign Assets Control 
regulations (31 CFR Part 500 et al). 



7.0 DELIVERY OF ITEMS 

7.1 By prior arrangement with a receiving bank, a 

Reserve Bank sends items by electronic means to 

the receiving bank, or to a receiving point or ACH 

operator (other than a Reserve Bank) designated as 

its agent by the receiving bank. Alternatively, by 

prior agreement with a receiving bank, a Reserve 

Bank may deliver items by making them available 

on the Reserve Bank's system for the receiving 

bank or its agent to retrieve. The Reserve Bank has 

delivered such items when it has placed the items 

on a Reserve Bank storage device and made the 

items available for the receiving bank or its agent 

to retrieve. In emergency circumstances, the 

Reserve Bank sends items as arranged with the 

receiving bank, or by the same means and to the 

same location to which it sends cash items for the 

receiving bank. If the receiving bank requests that 

items he sent to or made available for pickup by 

another person, that person is the receiving bank's 

agent and is not a sender or receiving bank as 
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defined in Article 4A or a party to an item in 

acting as agent of the receiving bank, items are 

considered received by a receiving bank in 

accordance with applicable ACH rules, except as 

provided inparagraph 7.2A receiving bank should 

promptly advise its servicing Reserve Bank by 

telephone if it does not receive items by the 
expected date. 

7.2 A receiving bank must manage its electronic 
connection so as to permit it to receive items in a 
timely manner throughout the day. A receiving 
bank that does not receive items in a timely manner 
because it fails to so manage its electronic 
connection, or because of emergency 
circumstances beyond the control of a Reserve 
Bank, is required to settle for the items with a 
Reserve Bank on the settlement date, but is not 
considered to receive the items for purposes of the 
deadline for return, if the items are available timely 
for electronic transmission by a Reserve Bank to 
the receiving bank, or for pick-up at a Reserve 
Bank by the receiving bank. The receiving bank 
may choose next day debit with as of adjustment or 
explicit charge for float in lieu of settling on the 
settlement date for debit items. 



7.3 




8.0 



9.0 



DESIGNATION 

ACCOUNT 



OF SETTLEMENT 



8.2 



For purposes of this Circular and Article 4A, the 
receiving bank is deemed to have received an item 
from its Administrative Reserve Bank, regardless 
of which Reserve Bank holds the receiving bank's 
settlement account, maintains its electronic 
connection or sends the item to the receiving bank. 
No Reserve Bank, other than the receiving bank's 
Administrative Reserve Bank and the sending 
bank's Administrative Reserve Bank, is a party to 
the item or a sender or receiving bank under 
Article 4A. See paragraphs 3.2 and 3.3. 

TIME SCHEDULES, SETTLEMENT DATES 
AND EXTENSIONS OF TIME LIMITS 



8. 1 The ACH items time schedule (Appendix B) shows 
the banking days and theclosing hours for a 

Reserve Bank to receive credit and debit items of 
various classes for immediate or next day 
settlement. The time schedule also shows the 
effective date window for classes of items and 
provisions for settlement or various effective dates. 



The Reserve B anks process items in accordance 
with their processing schedules, and send them to 
the receiving bank on or before the settlement date. 
If, because of circumstances beyond a Reserve 
Bank's control, it is delayed beyond the applicable 
time limit in acting on an item (other than a credit 
item subject to Article 4 A), the time for acting is 
extended for the time necessary to complete the 
action, provided the Reserve Bank exercises such 
diligence as the circumstances require. 



9.1 Prior to sending an item to (or receiving an item 
from) a Reserve Bank, a sending bank (and a 
receiving bank) must designate to its 
Administrative Reserve Bank a settlement 
account(s) on a Reserve Bank's books, and identify 
the transactions to be settled through the 
account(s). See Operating Circular 1, "Account 
Relationships." If the bank designates a 
correspondent bank's account, the correspondent 
bank must agree to that designation. If the 
settlement account is on the books of another 
Reserve Bank, the other Reserve Bank must not 
object to the designation. A correspondent bank 
whose account is used by a sending or receiving 
bank for settlement of items, and a Reserve Bank, 
other than the sending or receiving bank's 
Administrative Reserve Bank, that holds the 
settlement account, does not thereby become a 
sender or receiving bank as defined in Article 4 A, 
or a party to an item. A sending or receiving bank 
remains responsible under this Circular for all 
transactions, notwithstanding that it has designated 
a settlement account, including a settlement 
account maintained by a correspondent bank. A 
Reserve Bank may in its discretion, recover the 
unpaid balance of the sending or receiving bank ' s 
obligation with respect to an item from the sending 
or receiving bank, respectively, without prior 
notice or demand. 

9.2 A Reserve Bank may charge against a sending or 
receiving bank's account the amount of the bank's 
ACH transactions, unless the bank makes other 
arrangements for settlement. 

9.3 By designating a settlement account/a bank (or a 
correspondent bank, if any) authorizes the Reserve 
Bank that holds the settlement account: ( 1 ) to debit 
to its account on the settlement date the amount of 
credit items sent by the bank to a Reserve Bank, 
the amount of debit items sent to the bank by a 
Reserve Bank, and the amount of Government 
ACH debit items sent to the bank by a Reserve 
Bank; (2) to credit to its account on the settlement 
date the amount of debit items sent by the bank to 
a Reserve Bank, the amount of credit items sent to 
the bank by a Reserve Bank, and the amount of 
Government ACH credit items sent to the bank by 
a Reserve Bank; and (3) to debit and credit to its 
account me amount of other transactions (including 
fees, unless otherwise agreed) with respect to ACH 
Items and Government ACH Items as provided in 
this Circular. 



9.4 



The bank (or a correspondent bank, if any) agrees 
to maintain to its credit in its account, consistent 
with paragraph 10 of this Circular, a balance of 
actually and finally collected funds sufficient to 
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cover charges under this Circular and all other 
charges to its account. The Reserve Banks assume 
no responsibility for any obligations or rights of 
a bank with respect to its correspondent bank, if 
any (or of an intermediary correspondent that is 
not an account holder, if any, with respect to its 
correspondent account holder). 

9.5 By designating a settlement account, and in 
consideration of the processing and settlement by 
the Reserve Banks of items sent to and/or received 
by the bank and other sending and receiving banks, 
the bank (and its correspondent bank, if any) 
agrees to the Reserve Banks' Circular entitled 
"ACH Items" and to the applicable ACH rules, 
each as amended from time to time, for the benefit 
of all parties interested in the items. 

9.6 A settlement designation supersedes all prior 
inconsistent designations with respect to items. The 
sending or receiving bank may terminate a 
settlement designation by written notice to the 
Reserve Bank that holds the account (and the 
Reserve Bank may terminate a settlement 
designation by written notice to the bank) effective 
five banking days after receipt of the notice or on 
a subsequent date specified in the notice. A 
correspondent bank (or an intermediary 
correspondent that is not an account holder, if any) 
may terminate a settlement designation by written 
notice to the Reserve Bank that holds the 
settlement account, effective only for ACH items to 
be settled on and after the banking day following 
the banking day of receipt of the notice, or on a 
later date specified in the notice. A sending or 
receiving bank must designate another settlement 
account if its correspondent bank suspends 
payment or is closed, if the authority to charge the 
correspondent's account is terminated, or if the 
correspondent's Administrative Reserve Bank 
judges, in its discretion, that there will not be 
sufficient funds in the account on the settlement 
date to cover an item. 

10.0 SETTLEMENT 

10.1 A sending or receiving bank's settlement 
obligation is owed to its Administrative Reserve 
Bank, even if it has designated an account on 
another Reserve Bank's books for settlement. 
Settlement with the Reserve Bank that holds the 
settlement account is deemed to be settlement with 
the sending or receiving bank's Administrative 
Reserve Bank. 

10.2 On the settlement date, the Reserve Bank that 
holds the sending bank's settlement account debits 
(or credits) that account in the amount of a credit 
(or debit) item, and the Reserve Bank that holds 
the receiving bank's settlement account credits (or 
debits) the receiving bank's account in the amount 



of the credit (or debit) item. Settlement for credit 
items must be made by the sending bank at the time 
provided in Appendix B, and credit for credit items 
is available for withdrawal or other use by the 
receiving bank at that time, subject to the 
provisions of this Circular. Settlement for debit 
items must he made by the receiving bank at the 
time provided in Appendix B, and credit for debit 
items is available for withdrawal or other use by 
the sending bank at that time, subject to the 
provisions of this Circular. 



SECURITY INTEREST 

10.3 To secure any obligation, now existing or arising in 
the future, in connection with an ACH item by a 
sending or receiving bank (or by a correspondent 
bank whose account a sending or receiving bank 
uses for settlement) to a Reserve Bank, the bank 
grants to the Reserve Bank all the bank's right, 
title, and interest in property, whether now owned 
or hereafter acquired, in the possession or control 
of, or maintained with, any Reserve Bank, 
including but not limited to the bank's deposit 
account maintained with any Reserve Bank, items 
in the process of collection and their proceeds, and 
any investment property (including securities, 
security entitlements, and security accounts), but 
excluding any investment property which the bank 
may not encumber under applicable law. This 
security interest is in addition to any other security 
interest granted to a Reserve Bank by the bank 
under regulation or agreement. The secured 
Reserve Bank may take any action authorized by 
law to recover the amount owed to it by the bank, 
including but not limited to the exercise of setoff 
without demand or notice and even if the 
obligations are contingent or unmatured, the 
realization on any available collateral, and the 
exercise of any rights it may have as a creditor 
under applicable law. 




REFUSAL TO SETTLE 

10.4 If the Reserve Bank that holds the settlement 
account judges, in its discretion, that there may not 
be sufficient funds in the account at the settlement 
time provided in Appendix B on the settlement 
date to cover a debit for a credit item (including a 
credit item subject to Article 4A) or for a debit 
item, the Reserve Banks may cease processing the 
item and may refuse to settle for it. The Reserve 
Banks may also cease processing and refuse to 
settle for an item if they receive notice of the 
suspension or closing of the sending or receiving 
bank (other than the sending bank of a prefimded 
credit item) prior to the time settlement is final 
under this Circular. If the Reserve Banks cease 
processing or refuse to settle for an item, they will 
notify the sending bank and a receiving bank to 
which the item has been sent (or a correspondent 
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bank whose account a bank uses for settlement) as 
soon as possible. 

1 1 .0 AVAIL ABILITY OF CREDIT 

DEBITITEMS . ... ; :.V;,. 

■11.1 Credit given for a debit item by the Reserve Bank 
that holds the sending bank's settlement account is 
available for use and may qualify as reserve for 
purposes of Regulation D (12 CFR Part 204) on 
the settlement date, subject to paragraph 10.7, this 
paragraph, and other provisions of this Circular. 
The Reserve Bank may refuse to permit the use of 
credit given for a debit item if it judges that there 
may not he sufficient funds in the sending bank's 
settlement account to cover chargeback or return of 
the item. If a Reserve Bank does not receive 
actually and finally collected funds in settlement of 
a debit item at or before 8:30 a.m. ET on the 
barring day following the settlement date, the 
Reserve Banks that hold the sending and receiving 
banks' settlement > accounts may reverse the debit 
and credit previously made in settlement of the 
item by 8:30 a.m. ET, and will notify the sending 
and receiving banks (or a correspondent bank 
whose account a bank uses for settlement) as soon 
as possible. 

CREDIT ITEMS 

11.2 Credit given by the Reserve Bank that holds the 
receiving bank's settlement account for a credit 
item (including a credit item subject to Article 4A) 
is final and available for use and may qualify as 
reserve for purposes of Regulation D (12 CFR Part 
204) at the settlement time provided in Appendix 
B on the settlement date. 

12.0 RECEIVING BANK'S AGREEMENTS 

12.1 A receiving bank, by maintaining or using an 
account with a Reserve Bank for settlement of 
items or by accepting an item from a Reserve 
Bank: 



(a) agrees to comply with the applicable ACH 
rules and agrees that those rules govern the 
relationships among the sending bank, the 
receiving bank and other parties interested 
in the item and covered by those rules; 

(b) agrees to process the item in accordance 
with this Circular; 

(c) authorizes the Reserve Bank holding the 
receiving bank's settlement account to 
credit the amount of a credit item, or debit 
the amount of a debit item, to the receiving 
bank's settlement account on the settlement 
date; and 



(d) agrees to indemnify each Reserve Bank 
processing or settling for the item for any 
loss or expense (including attorneys' fees 
and expenses of litigation) incurred as a 
result of a breach of the foregoing 
agreements or of any action taken by the 
Reserve Bank in accordance with its 
Circular. 

12.2 The agreements, authorization and indemnity in 
paragraph 12.1 do not limit any other agreement, 
authorization or indemnity not inconsistent with 
paragraph 12. 1, made by a receiving bank to a 
sending bank, a Reserve Bank or another person. 

13.0 REVOCATION OF ITEMS 

13.1 A sending bank or prior party may not amend or 
revoke an item after it has been received by a 
Reserve Bank, except as provided in applicable 
ACHrules. 

13.2 A Reserve Bank may cancel items by initiating a 
reversing batch of items in accordance with 
applicable ACH rules if it discovers that a Reserve 
Bank sent a duplicate or erroneous batch of items. 
The Reserve Bank will notify the sending bank 
accordingly. Nothing in this Circular constitutes a 
waiver by any Reserve Bank of a right of recovery 
under the applicable law of mistake and restitution. 

14.0; RETURN OF ITEMS AND FUNDS 

14. 1 A receiving bank may return a debit or credit item 
to any Reserve Bank in accordance with the 
applicable ACH rules and by the closing hour set 
forth in the ACH time schedule. The receiving 
bank is accountable for the amount of a debit item 
if the returned item is not received by that closing 
hour. 

14.2 The Reserve Banks process a returned item they 
receive from a receiving bank and send it or make 
it available to the sending bank in accordance with 
the provisions of this Circular governing the 
processing of items. On the settlement date, the 
Reserve Bank that holds the sending bank's 
settlement account debits or credits that account in 
the amount of areturned debit or credit item, and 
the Reserve Bank that holds the receiving bank's 
settlement account credits or debits that account in 
the amount of the returned debit or credit item at 
the time provided in Appendix B, subject to the 
provisions of this Circular governing the settlement 
for items. 

14.3 A receiving bank should keep records that permit 
it to identify the source of receipt of items. By 
sending a returned debit item to a Reserve Bank, a 
receiving bank: 
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(a) agrees on request to provide records 
showing whether it received the debit item 
from a Reserve Bank, and 

(b) if it did not receive the debit item from a 
Reserve Bank, agrees to indemnify the 
Reserve Banks for loss resulting from a 
Reserve Bank's failure to receive the 
amount of the returned debit item from the 
sendingbank. 

14.4 If a receiving bank sends an adjustment entry for 
an unauthorized debit item to a Reserve Bank in 
accordance with applicable ACH rules, the 
receiving bank agrees to indemnify the Reserve 
Banks for loss resulting from a Reserve Bank's 
failure to receive the amount of the adjustment 
from the sending bank, whether or not the 
receiving bank received the debit item from 
a Reserve Bank. 

15.0 DISPUTED RETURNS 

15.1 If a sending bank disputes the propriety of a 
returned item one time in accordance with 
applicable ACH rules, the Reserve Bank(s) that 
holds the sending bank's and the receiving bank's 
settlement accounts will provisionally settle for the 
disputed return, subj ect to receipt of funds from the 
receiving bank. If the receiving bank disputes the 
sending bank' s claim in accordance with applicable 
ACH rules, the Reserve Bank(s) will reverse the 
provisional settlement for the disputed return, 
subject to receipt of funds from the sending bank. 

16.0 ADVICES OF CREDIT AND DEBIT; 
REPORTING OF ERRORS 

16. 1 A Reserve Bank provides, in a statement, advices 
of credit and debit to an account holder for items 
for which the account holder has agreed to settle. 
An advice of credit indicates that credit has been 
given, subject to the provisions of this Circular. A 
Reserve Bank also, on request, provides advices to 
a person other than the bank or its correspondent, 
as the bank's agent, in accordance with paragraph 
7 of this Circular. 

16.2 A Reserve Bank properly executes a credit item 
subject to Article 4 A if it sends an advice of credit 
as requested by the receiving bank. A sending or 
receiving bank (and a correspondent bank, if any) 
agree that a reasonable time to notify its servicing 
Reserve Bank concerning an unauthorized or 
erroneously executed item is within thirty calendar 
days after the bank (or correspondent) receives an 
advice of debit. Notice after that time may 
constitute the failure to exercise ordinary care, 
precluding the recovery by the bank of interest 
(with respect to a credit item subject to Article 4A) 
and other damages (with respect to other items). 



16.3 In addition to the requirement for prompt notice 
under paragraph 16.2. and Sections 4A-204 and 
4A-304 of Article 4A, a sending or receiving bank 
(or a correspondent account holder, if any) shall 
notify its servicing Reserve Bank immediately if it 
learns of or discovers, from any source other than 
an advice of debit from the Reserve Bank, the 
possibility of error or lack of authority in the 
transmission or processing of an item. See also 
paragraph 4. 

17.0 RECORDS 

17.1 Each sending and receiving bank should keep 
records that permit it to resolve questions that arise 
concerning the handling of items, and to resend 
items if a Reserve Bank notifies it that the items 
have been lost because of a computer outage or 
other reason. A Reserve Bank keeps records of 
items processed for only one year after the 
settlement date. 

18.0 FEES 

18.1 The ACH Fee Schedule shows the charges 
imposed for processing and settlement of items. A 
Reserve Bank may make the charge to the sending 
or receiving bank's account, as otherwise agreed 
with the sending or receiving bank, or to the 
account designated by the sending or receiving 
point or ACH operator (other than a Reserve 
Bank), as applicable. 

19.0 NON-VALUE MESSAGES 

19.1 The Reserve Banks handle a message that does not 
result in an accounting entry, such as a 
prenotification or notification of change, in the 
same manner as an item except that no funds are 
transferred. A Reserve Bank's liability for damage 
caused by its failure to exercise ordinary care, or 
by its own or its employees' willful misconduct, in 
processing a non- value message may not exceed 
the amount of any fee paid to a Reserve Bank for 
the message. 

20.0 ADDITIONAL INFORMATIONAL 
SERVICES 

20.1 For banks that access our ACH services through a 
web-based connection, the Reserve Bank provides 
informational services in addition to the clearing 
nd settlement services described above in this 
Circular. Banks may access and use the Reserve 
Bank's systems via a web-based connection, to 
obtain and view information or reports related to a 
bank's use of the ACH service, subject to the terms 
and conditions in this paragraph 20. 

20.2 The Reserve Bank routinely deletes from its 
systems information that is no longer current. This 
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paragraph does not create any right to access 
information that has been deleted from the 
Reserve Bank's systems in the ordinary course of 
business. 

20.3 With respect to any use that a bank makes of the 
Reserve Bank' s informational services under this 
paragraph, as distinct from the clearing and settling 
services provided by the Reserve Bank under other 
provisions of this Circular, the Reserve Bank shall 
be liable only to the bank, and not to any third 
party, and only for loss or damage proximately 
caused by the Reserve Bank's failure to exercise 
ordinary care or by its own or its employees' 
willful misconduct, and only up to the amount of 
any access fees paid by the bank to the Reserve 
Bank for a FedLine Web connection to the 
FedACH system during the preceding one month 
period. 

21.0 RESERVE BANK LIABILITY; ITEM OTHER 
THAN CREDIT ITEM SUBJECT TO 
ARTICLE4A 

LIMITATIONS ON LIABILITY 



21. 




1 With respect to an item other than a credit item 
subject to Article 4A: 

(a) a Reserve Bank is responsible or liable only 
to a sending bank, a receiving bank or 
another Reserve Bank, and only for its own 
failure to exercise ordinary care, or for its 
own or its employees' willful misconduct; 

(b) a Reserve Bank does not act as the agent or 
subagent of another bank or person and is 
not liable for the insolvency, neglect, 
misconduct, mistake or default of another 
bank or person; 

(c) a Reserve Bank does not make any warranty 
with respect to an item it processes or settles 
for under this Circular; and 

'.'■■■(d) no person may make a claim againsta 
Reserve Bank for loss resulting from the 
Reserve Bank's processing of or settling for 
an item after one year from the settlement 
date of the item. If a bank (or correspondent 
bank, if any) does not send written objection 
to an advice of debit to its servicing Reserve 
Bank within thirty calendar days after 
receipt of the advice, it is deemed to 
approve the debit on its own behalf (and on 
behalf of a sending or receiving bank using 
the account for settlement, if any). 



MEASURE OF DAMAGES 

21.2 The measure of damages for a Reserve Bank's 
failure to exercise ordinary care, or for its own or 
its employees' willful misconduct, is as follows: 

(a) for a credit item (including a returned credit 
item but excluding a credit item subject to 
Article 4A), its liability is limited to 
damages that are attributable directly and 
immediately to the failure to exercise 
ordinary care or to the willful misconduct, 
and does not include damages that are 
attributable to the consequences of such 
conduct, even if such consequences were 
foreseeable at the time of such conduct. 

(b) for a debit item (including a returned debit 
item), its liability for its failure to exercise 
ordinary care is limited to the amount of the 
item reduced by an amount that could not 
have been realized by the use of ordinary 
care. Where there is willful misconduct with 
respect to a debit item, the measure of 
damages includes other damages that are 
attributable directly and immediately to the 
willful misconduct, but does not include 
damages that are attributable to the 
consequences of such misconduct, even if 
such consequences were foreseeable at the 
time of such misconduct. 

22.0 RESERVE BANK LIABILITY; CREDIT 
ITEM SUBJECT TO ARTICLE 4A 

LIABILITY 



22.1 



A Reserve Bank's liability with respect to a credit 
item subject to Article 4A is governed by Article 
4A, except as otherwise provided in this Circular. 
A Reserve Bank is not liable with respect to a 
credit item subject to Article 4A for any damages 
other than those payable under Article 4 A. A 
Reserve Bank shall not agree to be liable for 
consequential damages with respect to a credit item 
subject to Article 4A under Section 4A-305(d) of 
Article 4A. 



AS OF ADJUSTMENTS 

22.2 A Reserve Bank may in its discretion, satisfy, its or 
another Reserve Bank's obligation to pay 
compensation in the form of interest under Article 
4Aby: 

(a) providing an as of adjustment to a sending 
or receiving bank in an amount equal to the 
amount on which interest is to be calculated 
multiplied by the number of days for which 
interest is to be calculated; or 
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(b) paying compensation in the form of interest 
to a sending bank, receiving bank or another 
party to the item that is entitled to such 
payment, in an amount calculated in 
accordance with Section 4 A-506 of Article 
4A. 

22.3 If a sending or receiving bank that receives an as of 
adjustment in the form of a credit, or an interest 
payment, is not the party entitled to compensation 
under Article 4 A, the bank shall pass through the 
benefit of the adjustment or payment by making an 
interest payment (as of the day the adjustment or 
payment is made) to the party entitled to 
compensation. The interest payment that is made to 
the party entitled to compensation shall not be less 
than the value of the as of adjustment or interest 
payment that was provided by the Reserve Bank to 
the sending or receiving bank. The party entitled to 
compensation may agree to accept compensation in 
a form other than a direct interest payment, if the 
alternative form of compensation is not less than 
the value of the interest payment that otherwise 
would be made. 

22.4 A Reserve Bank may make an as of adjustment 
pursuant to paragraph 22.2 as follows: 

(a) The Reserve Bank will normally process 
and apply an as of adjustment to the reserve 
maintenance period during which the 
transaction giving rise to the obligation to 
pay interest occurred, so that there will be 
no impact on aggregate reserves. If the 
Reserve Bank determines that is not 
feasible, in its sole discretion, it will process 
and apply the as of adjustment to the current 
reserve period. 

(b) If an as of adjustment would be applied to 
one of the last three days of a reserve 
maintenance period, the Reserve Bank may 
apply it to either the current or future 
reserve maintenance periods. 

(c) If a Reserve Bank delays execution of a 
credit item subject to Article 4A (see 
Section 4A-305(a) of Article 4A), the 
Reserve Bank may make an as of credit 
adjustment to the receiving bank's account. 
If the sending bank was not debited at the 
appropriate time, the Reserve Bank will 
make an offsetting as of debit adjustment to 
the sending bank's account. 



(d) If a Reserve Bank misdirects a credit item 
subject to Article 4A (see Sections 4A- 
303(c) and 4A-305(b) of Article 4 A), the 
Reserve Bank may make an as of credit 
adjustment to the account of the bank that 
should have received the order. If agreed by 



the bank that received the misdirected order, 
the Reserve Bank will make an offsetting as 
of debit adjustment to the receiving bank's 
account. 

(e) If a Reserve Bank sends a credit item 
subject to Article 4A in an amount less than 
the amount that was intended (see Sections 
4A-303(b) and 4A-305(b) of Article 4A), 
the Reserve Bank may make an as of credit 
adjustment to the receiving bank's account. 
If the sending bank was not debited in the 
appropriate amount, the Reserve Bank will 
make an as of debit adjustment to the 
sending bank's account. 

(f) If a Reserve Bank issues a duplicate credit 
item subject to Article 4 A or a credit item 
subject to Article 4A that is in an amount 
more than was intended (see Sections 4A- 
303(a) and 4A-305(b) of Article 4A), and if 
the sending bank's account was not debited 
in the appropriate amount, the Reserve 
Bank may make an as of credit adjustment 
to the sending bank's account. If agreed by 
the receiving bank, the Reserve Bank will 
make an as of debit adjustment to the 
receiving bank's account. 

(g) If a Reserve Bank delays rejection of a 
credit item subject to Article 4A (see 
Sections 4A-209(b) and 4 A-2 10(b) of 
Article 4A), the Reserve Bank may make an 
as of credit adjustment to the sending 
bank's account 




(h) A Reserve Bank will apply offsetting as of 
adjustments to the same reserve 
maintenance periods to the extent feasible. 

23.0 FORUM FOR ACTION 

23 . 1 Any action against a Reserve Bank for that Reserve 
Bank's acts or omissions relating to the clearing of 
or settlement for an ACH item must be brought in 
the United States District Court and Division 
where the office or branch of the Reserve Bank 
that committed the alleged act or omission is 
located. 

24.0 RECOVERY BY RESERVE BANK 

24.1 If an action or proceeding is brought against a 
Reserve Bank based on: 

(a) an alleged breach of (or an alleged failure to 
have the authority to make) any of the 
authorizations and agreements referred to in 
paragraphs 5.1 and 12.1 of this Circular by 
the sending or receiving bank, or an alleged 
breach of the applicable ACH rules by the 
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sending bank, the receiving bank or another 
Reserve Bank; or 

(b) any action by the Reserve Bank in 
accordance with its Circular; the Reserve 
Bank may recover from the sending bank, 
the receiving bank or the other Reserve 
Bank, as the case may be, any amount the 
Reserve Bank is required to pay under a 
final judgment or decree, together with 
interest, and the amount of attorneys' fees 
and other expenses of litigation incurred. 

24.2 The Reserve Bank may recover the amount stated 
in paragraph 24.1 by charging the sending or 
receiving bank's account (or if the item was 
received from, sent to, or settled to 
Reserve Bank, by charging the other Reserve 
Bank), if: 

(a) the Reserve Bank has made timely written 
demand on the sending bank, receiving 
bank, or other Reserve Bank to assume 
defense of the action or proceeding; and 

(b) no other arrangefnent for payment 
acceptable to the Reserve Bank has been 
made. 

A Reserve Bank that has been charged under this 
paragraph may recover from the sending or 
receiving bank in the manner and under the 
circumstances set forth in this paragraph. A 
Reserve Banks failure to avail itself of the remedy 
provided in this paragraph does not prejudice its 
enforcement in any other manner of the indemnity 
agreements referred to in paragraphs 5.1 and 12.1. 



25.0 RIGHT TO AMEND 

25.1 The Reserve Banks reserve the right to amend this 
Circular at any time without prior notice. 
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Appendix A 

ACH SECURITY PROCEDURES 

1.0 GENERAL 

1.1 The Reserve Banks offer the following security 
procedures to each sending bank that is authorized 
to send ACH items to a Reserve Bank, for the 
purpose of verifying the authenticity of the source 
of the AGH items. The security procedures are not 
used to detect an error in the transmission or the 
content of the ACH items. 

1.2 Prior to selecting any Security Procedure, a 
sending bank should consider the degree to which 
the various options satisfy the sending bank's 
business needs given the size, type and frequency 
of ACH items sent to a Reserve Bank. 

1.3 The Reserve Banks offer the following security 
procedures to each receiving bank that is 
authorized to receive ACH items from a Reserve 
Bank, for the purposes of verifying the authenticity 
of a request to retrieve ACH items and of 
maintaining the integrity and security of the 
Reserve Banks' data systems. 

2.0 LEVEL ONE SECURITY PROCEDURES 

2.1 The Reserve Banks offer one or more Level One 
Security Procedures. Level One Security 
Procedures are available to any bank that sends or 
receives ACH items by means of an encrypted 
communication connection between its facilities 
(or those of a Third Party Service Provider) and a 
Reserve Bank's facilities utilizing a 
hardware/software system specified by a Reserve 
Bank. A sending or receiving bank is responsible 
for ascertaining that its hardware and software 
systems comply with the Reserve Bank's 
specifications. 

2.2 Each of the Level One Security Procedures is 
comprised of the following: security protocols 
embedded in the hardware and software associated 
with the equipment used to initiate, transmit, or 
receive ACH items; access controls that grant 
access to the FedACH systems, such as 
identification codes, confidential passwords, and in 
some cases digital certificates on tangible media; 
and encryption of ACH items during the 
transmission process. All of the Level One Security 
Procedures require the bank to implement physical 
security as well as management controls that 
protect the hardware and software from 
unauthorized use. 

2.3 The primary differences between the various Level 
One Security Procedures relate to the strength of 



the encryption algorithm, the type of software used 
to access a Reserve Bank's network, and the nature 
of the connection that a bank uses to access the 
Reserve Bank's systems. 

2.4 The procedures are more specifically described in 
security documentation provided by the Reserve 
Bank. For computer interface customers, this 
documentation includes the Computer Interface 
Protocol Specifications (CIPS), the Local Security 
Administrator Guide, and Operating Circular 5. 
For FedLine DOS customers, this documentation 
includes the FedLine Users Guide, the FedLine PC 
Administrator's Guide, the FedLine Management 
Guide, and Operating Circular 5. For FedLine 
Advantage customers, the documentation includes 
the "FedLine Advantage Technical Support 
Liaison Guide," the "FedLine Advantage EUAC 
Access Management Guide," the "FedLine 
Advantage Subscriber Guide," and Operating 
Circular 5, including the Certification Practice 
Statement. The bank is responsible for 
implementing the procedures set forth in the 
applicable security documentation pro vided to it by 
the Reserve Bank as well as any subsequent 
modification to the procedures that are designed to 
strengthen the security procedures. 

3.0 LEVEL TWO SECURITY PROCEDURE 

3.1 The Level Two Security Procedure is available to 
any bank that sends ACH items to a Reserve Bank 
by electronic transmission that does not include 
both encryption and access controls. It is also used 
when a bank that normally sends ACH items under 
one of the Level One Security Procedures defined 
above is unable to do so because of an equipment 
or communications failure or other circumstances. 

3.2 In the case of electronic transmission of ACH 
items, the Level Two Security Procedure is 
incorporated in the transmission process and, in 
general, includes either access controls or 
encryption. When ACH items are sent by magnetic 
tape, diskette, or electronic transmission that does 
not include either encryption or access controls, the 
Level Two Security Procedure includes a 
procedure whereby the sending bank or its agent 
provides file control information i.e., file ID, debit 
and credit dollar amounts, and entry/addenda count 
to a Reserve Bank and then the Reserve Bank 
compares that information against the file(s) it 
actually receives. The control information may be 
provided by: 

a) voice response if the voice response system 
contains an access security feature; 

b) a telephone call using codewords; or 



OC4 13 



OPERATING CIRCULAR 4 



2005 ACH RULES 



(c) 



a transmittal register or a telephone call. 
When the control information is provided 
by this means, it will be verified by a call 
back from the Reserve Bank. ' 




OC4 14 



2005 ACH RULES 



OPERATING CIRCULAR- 4 



Appendix Al 

ACH SECURITY PROCEDURE 
AGREEMENT 



Date: ■ .-■ ■.-. ■ ■ .-. : ." :■.■■■ 
To: Federal Reserve Bank of _ 



Attention: Manager: ACH Operations 

We agree to the provisions of the Federal Reserve Banks' 
Operating Circular entitled Automated Clearing House 
Items" and its appendices' (Circular"), as amended from 
time to time, and to the Reserve Bank's Operating 
Circular 5 entitled "Electronic Access" and the 
Certification Practice Statement incorporated in Operating 
Circular 5, as amended from time to time. 

If we use an encrypted communications line with access 
controls for the transmission of ACH Items to a Reserve 
Bank, we will choose one of the Level One Security 
Procedures as generally described in Appendix A to the 
Circular, as such security procedure may be modified 
from time to time by the Reserve Banks. If you offer more 
than one Level One Security Procedure, when we use one 
of the Level One Security Procedures, we reject the other 
Level One Security Procedure offered by you. We also 
agree that this procedure will be used if we receive ACH 
items by means of an encrypted electronic 
communications line with access controls. The chosen 
Level One Security Procedure will be used for the 
purpose of verifying that ACH items were sent or received 
by us. 

If we use a method other than an encrypted 
communications line with access controls for the 
transmission of ACH items, we reject the Level One 
Security Procedures and choose the Level Two Security 
Procedure generally described in Appendix A to the 
Circular, as such security procedure may be modified 
from time to time by the Reserve Banks. This security 
procedure will be used for the purpose of verifying that 
ACH items were sent or received by us. 

We understand that the Level Two Security Procedure as 
well as any of the Level One Security Procedures may be 
deemed commercially reasonable pursuant to Section 4 A- 
202(c) of Article 4A of the Uniform Commercial Code. 

Whenever we choose to use one of the Level One Security 
Procedures or the Level Two Security Procedure, we 
agree to be bound by any ACH item, whether or not 
authorized, sent in our name and accepted by a Reserve 
Bank in compliance with such procedure. 

We understand that the Level One and Level Two 
Security Procedures will not be used to detect any error in 
the transmission or content of ACH items. 



We also understand and agree that the security procedures 
established by this Agreement may be changed only by an 
amendment to Appendix A or other written agreement. 
The Agreement may not be changed by an oral agreement 
or by a course of dealing or custom. 

Name ofBank 



Office Authorized Signature 
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A ppendixB 

AGH ITEMS TIME SCHEDULE 



.1.0 



Li 



BANKING DAY; CLOSING TIMES; 

SETTLEMENT TIMES 

This time schedule shows the Reserve Banks' 
banking day for processing ACH items, the closing 
times for receipt of ACH files for settlement on the 
dates set forth in this Appendix, and the times for 
settlement of ACH Items. 



1,2 Banking Day. The Reserve Banks' banking day 
for receipt of ACH items is from 3:00 a.m. ET to 
2:59 a.m. ET on the next calendar day. 3 



1.3 Closing Times 4 



Immediate Settlement 
(Returns and NACS Items) 



Automated Items 

Voice Response Returns 
and Telephone Return Debit 
Items of $2,500 or more 



2:00 p.m. ET 
1:30 p.m. ET 



End of Day 5 
2:15 a.m. ET 
8:00 p.m. ET 




Paper Returns and NOCs 8:00 a.m. ET 

1 .4 Settlement Times. Credit items are settled at 8:30 
a.m. ET. Debit items are settled at 1 1 :00 a.m. ET. 
Immediate settlement items are settled at 5 :00 p.m 

■ ET. ■■ 

2.0 EFFECTIVE DATE WINDOWS 

2.1 Items (other than returns, notifications of change 
(NOCs) and NACS items) should specify an 
effective date within the following effective date 



Reserve Banks process and transmit files up until 6:00 
a.m. ET on the calendar day on which the banking day ends. Certain 
other times apply before and after weekends and holidays. All times 
listed are Eastern Time. 



Closing times represent the end of the deposit window. 
Files must be completely received (e.g.. data transmission fully 
concluded) by the closing time. Sending banks should coordinate the 
beginning of their transmission within the window to ensure 
completion by the closing time. Deposits of 500,000 items or more 
must be received one-half hour earlier than the indicated deadline. 
Sending banks using non-electronic means for transmission, due to 
contingency situations, may be required to submit tapes at earlier 
deadlines. 



windows, computed from the Reserve Banks' 
banking day of receipt. 

Class Effective Date Window 

Credit Items One or Two Banking Days 

Debit Items One Banking Day Only 

Items received with an effective date later than the 
effective date window will be returned to the 
sender. 



3.0 SETTLEMENT DATES 

3.1 Items with an effective date of one banking day are 
settled on the Reserve Banks' banking day 
following the banking day of receipt. Items withan 
effective date of two banking days are settled on 
the second banking day following receipt. The 
settlement date for immediate settlement items 
(returns and NACS items) that are received by the 
closing time for immediate settlement items is the 
banking day of receipt. 

3.2 If an effective date is not specified, or if an item 
specifies an effective date the same as or earlier 
than the Reserve Banks' banking day of receipt, 
the settlement date is the banking day following 
receipt. If an item specifies a settlement date that is 
a standard Reserve Bank holiday, the settlement 
date is the next banking day for the Reserve Banks. 

3.3 If an item specifies a settlement date that is not a 
banking day for the sending bank or the receiving 
bank, settlement is effected, with respect to that 
party, as follows: 

Debit Items : 

Sending bank closed : Credit sending bank' s 
account on settlement date. Receiving bank closed: 
Debit receiving bank's account on settlement date, 
or receiving bank may choose next day debit with 
as of adjustment or explicit charge for float. 



Credit Items : 

Sending bank closed: Debit 
account on settlement date. 



sending bank's 



Receiving bank closed: Credit receiving bank's 
account on settlement date. 

The receiving bank is not considered to receive an 
item made available to it on the day it is closed 
until its next banking day for purposes of 
determining the deadline for return. 



ACH Items must be received by the End of Day closing 
time to be processed as of the current banking day. 
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4.0 STANDARD HOLIDAYS 



4. 1 The Reserve Banks' banking days include all days 
except the following standard holidays : 6 

All Saturdays, 
All Sundays, 

New Year's Day (January 1), 
Martin Luther King's Birthday (third Monday in 
January), 

President's Day (third Monday in February), 
Memorial Day (last Monday in May), 
Independence Day (July 4), 
Labor Day (first Monday in September), 
Columbus Day (second Monday in October), 
Veteran's Day (November 1 1), 
Thanksgiving Day (fourth Thursday in November), 
■'■■'.■ and 

Christmas Day (December 25). 

If January 1 , July 4, November 1 1 , or December 25 
fall on a Sunday, the next following Monday is a 
standard Reserve Bank holiday. 




The New Orleans Branch of the Federal Reserve Bank 



of Atlanta may close on Mardi Gras. 
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A ppendix C 

PREFUNDING OF ACH CREDIT 

ORIGINATIONS BY 

SENDING OR CORRESPONDENT 

BANK 

1.0 GENERAL 

1 . 1 In order to reduce the risk of loss to Reserve Banks 
resulting from the finality of credit items, the 
Administrative Reserve Bank of a (sending or 
correspondent) bank that settles for credit item 
originations and whose account the Reserve Bank 
monitors in real time may notify the bank to 
prefund in accordance with this Appendix credit 
items that settle through the bank's account at the 
time a Reserve Bank processes the items. 

A sending bank, by sending credit items, and a 
correspondent bank, by agreeing to settle for items, 
agree as follows: 

2.0 DEFINITIONS 

2.1 For purposes of this Appendix: 

Settling bank means a sending bank that originates 
credit items, or the correspondent bank whose 
account the sending bank uses for settlement, that 
has been notified by its Administrative Reserve 
Bank that it must prefund the credit item 
originations that settle through its account. 

Prefund means to pay, in actually and finally col 
lected funds, to the settling bank's Administrative 
Reserve Bank, the total amount of all ACH credit 
item originations, including credit items originated 
through an ACH operator (other than a Reserve 
Bank), at the time a Reserve Bank processes the 
items. f 



Reserve Banks may, in their discretion, refuse to 
process any batch containing credit item 
originations (including a batch with both credit 
items and debit items) that has not been prefunded. 
If the settling bank only partially prefunds the total 
amount of ACH credit item originations, the 
Reserve Banks may, in their sole discretion, 
determine which batch of credit items shall be 
considered to have been prefunded, or may refuse 
to settle for all the items, and will notify the 
sending (and a settling correspondent) bank. 

33 If the settling bank prefunds the ACH credit items 
originated, its obligation to settle in respect of the 
prefunded ACH credit items originated up to the 
amount of the prefunding shall be automatically 
satisfied and discharged and replaced by an 
irrevocable obligation of a Reserve Bank to settle 
for me prefunded items on the settlement date. 

3.4 A Reserve Bank shall have no obligation to the 
settling bank for interest or other compensation or 
adjustment for the prefunded amount between the 
date of prefunding and the settlement date. 

4.0 MISCELLANEOUS 



4.1 



4.2 



4.3 



4.4 



The Reserve Banks reserve the right to defer the 
availability of some or all of the credit arising from 
ACH debit items originated by the sending bank. 

The Reserve Banks shall have no responsibility for 
any rights or obligations between a sending bank 
and its correspondent relating to this Appendix. 

To the extent of any inconsistency between this 
Appendix and the Circular, the provisions of this 
Appendix shall govern. 

The Reserve Banks reserve the right to amend this 
Appendix at any time without prior notice. 



3.0 PREFUNDING OF ACH CREDIT ITEMS 

3.1 The settling bank's Administrative Reserve Bank 
may in its discretion, by notice to the settling bank, 
require that the settling bank irrevocably make 
available to the Administrative Reserve Bank, in 
actually and finally collected funds, the total 
amount of all ACH credit item originations at the 
time a Reserve Bank processes the items (to 
prefund). The settling bank authorizes its 
Administrative Reserve Bank, at the time a 
Reserve Bank processes the items, to deduct from 
the settling bank's account the amount needed to 
prefund the credit items. 

3.2 If the settling bank fails or refuses to prefund the 
full amount of ACH credit items originated, the 
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A ppendix D 
GOVERNMENT ACH ITEMS 

1. The Reserve Banks handle ACH items for which an 
agency of the Federal Government is the sending 
bank or the receiving bank (Government ACH items) 
as fiscal agents of the United States under Treasury 
Department regulations, including 31 CFRParts210, 
203 and 370, and Treasury procedures. As to matters 
those regulations and procedures do not cover, this 
Circular applies. The rules and procedures may differ 
as between commercial and Government ACH items, 
and as between Government ACH items of different 
types. 

2. A Reserve Bank makes the amount of all Government 
credit items sent to a receiving bank available for 
withdrawal or other use by the receiving bank at 8:30 
a.m. Eastern Time. A Reserve Bank may cease acting 
on a Government ACH item at any time upon 
direction of the Treasury Department, and will so 
notify the bank. 

3. Unless expressly authorized in writing by the 
Treasury Department, a sending bank shall not, under 
any circumstances, send a debit item designating the 
Government as receiving bank. 



4. A Reserve Bank shall not have or assume any 
responsibility or liability to any person other than the 
Treasury Department with respect to Government 
ACH items. 
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2005 ACH RULES 



REGULATION E 



REGULATION E 

ELECTRONIG FUND TRANSFERS 

FEDERAL RESERVE SYSTEM 
12CFRPart205 

ELECTRONIG FUND TRANSFERS 
(REGULATION E) 

■ Sec. 

205.1 Authority and purpose. 

205.2 Definitions. 

205.3 Coverage. 

205.4 General disclosure requirements; jointly 
offered services. 

205.5 Issuance of access devices. 

205.6 Liability of consumer for unauthorized 
transfers. 

205.7 Initial disclosures. 

205.8 Change in terms notice; error resolution 
notice. ; : ; 

205.9 Receipts at electronic terminals; periodic 
statements. 

205.10 Freauthorized transfers. 

205.11 Procedures for resolving errors. 

205.12 Relation to other Saws. 

205.13 Administrative enforcement; record, 
retention. 

205.14 Electronic fund transfer service provider not 
holding consumer's account. 

205.15 Electronic fund transfer of government 
benefits. 

205.16 Disclosures at automated teller machines. 

205.17 Requirements for electronic communication. 

Appendix A to Part 205— Model Disclosure Clauses 
and Forms 

Appendix B to Part 205-Federal Enforcement 
Agencies 

Appendix € to Part 205«Issuance of Staff 
Interpretations 

Supplement 1 to Part 205-Official Staff 
Interpretations 



§205.1 Authority and purpose. 

(a) Authority /This regulation, known as Regulation E, 
is issued by the Board of Governors of the Federal 
Reserve System pursuant to the Electronic Fund Transfer 
Act (15 U.S.C 1693 ^seg.). The information-collection 
requirements have been approved by the Office of 
Management and Budget under 44 U.S.C. 3501 et'seg.-' 
and have been assigned OMB No. 7100-0200. 

(b) Purpose . This regulation carries out the purposes of 
the Electronic Fund Transfer Act, which establishes the 
basic rights, liabilities, and responsibilities of consumers 
who use electronic fund transfer services and of financial 
institutions that offer these services. The primary 
objective of the act and this regulation is the protection of 
individual consumers engaging in electronic fund 
transfers. 

§ 205.2 Definitions. 

For purposes of this regulation, the following definitions 
apply: 

(a) (1) Access device means a card, code, or other 
means of access to a consumer's account; or any 
combination thereof, that may be used by the 
consumer to initiate electronic fund transfers. 

(2) An access device becomes an accepted 
access device when the consumer: 

(i) Requests and receives, or signs, or uses 

(or authorizes another to use) the 
access device to transfer money 
between accounts or to obtain money, 
property, or services; 

(ii) Requests validation of an access device 

issued on an unsolicited basis; or 

(iii) Receives an access device in renewal 
of, or in substitution for, an accepted 
access device from either the financial 
institution that initially issued the 
device or a successor. 

(b) ( 1 ) Account means a demand deposit (checking), 
savings, or other consumer asset account (other 
than an occasional or incidental credit balance in 
a credit plan) held directly or indirectly by a 
financial institution and established primarily for 
personal, family, or household purposes. 
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(2) The term does not include an account held by 
a financial institution under a bona fide trust 
agreement 

(c) Act means the Electronic Fund Transfer Act (title IX 
of the Consumer Credit Protection Act, 15 U.S.C. 1 693 et 

(d) Business day means any day on which the offices of 
the consumer's financial institution are open to the public 
for carrying on substantially all business functions. 

( e ) Consumer means a natural person. 

(f) Credit means the right granted by a financial institution 
to a consumer to defer payment of debt, incur debt and 
defer its payment, or purchase property or services and 
defer payment therefor. 

(g) Electronic fund transfer is defined in § 205.3. 

(h) Electronic terminal means an electronic device, other 
than a telephone operated by a consumer, through which 
a consumer may initiate an electronic fund transfer. The 
term includes, but is not limited to, point-of-sale 
terminals, automated teller machines, and cash dispensing 
machines. 

(i) Financial institution means a bank, savings association, 
credit union, or any other person that directly or indirectly 
holds an account belonging to a consumer, or that issues 
an access device and agrees with a consumer to provide 
electronic fund transfer services. 

(j) Person means a natural person or an organization, 
including a corporation, government agency, estate, trust, 
partnership, proprietorship, cooperative, or association. 

(k) Preauthorized electronic fund transfer means an 
electronic fund transfer authorized in advance to recur at 
substantially regular intervals. 

(1) State means any state, territory, or possession of the 
United States; the District of Columbia; the 
Commonwealth of Puerto Rico; or any political 
subdivision of the above. 

(m) Unauthorized electronic fund transfer means an 
electronic fund transfer from a consumer's account 
initiated by a person other than the consumer without 
actual authority to initiate the transfer and from which the 
consumer receives no benefit. The term does hot include 
an electronic fund transfer initiated: 

(1) By a person who was furnished the access 
device to the consumer's account by the 



consumer, unless the consumer has notified the 
financial institution that transfers by that person 
are no longer authorized; 

(2) With fraudulent intent by the consumer or 
any person acting in concert with the consumer; 
or 

(3) By the financial institution or its employee. 
§ 205,3 Coverage. 

( a ) General . This regulation applies to any electronic fund 
transfer that authorizes a financial institution to debit or 
credit a consumer's account. Generally, the regulation 
applies to financial institutions. For purposes of §§ 
205.10(b), (d), and (e) and 205.13, the regulation applies 
to any person. 



(b) Electronic fund transfer . The term electronic fund 
transfer means any transfer of funds that is initiated 
through an electronic terminal, telephone, computer, or 
magnetic tape for the purpose of ordering, instructing, or 
authorizing a financial institution to debit or credit an 
account. The term includes, but is not limited to: 

(1) Point-of-sale transfers; 

(2) Automated teller machine transfers; 

(3) Direct deposits or withdrawals of funds; 

(4) Transfers initiated by telephone; and 

(5) Transfers resulting from debit card 
transactions, whether or not initiated through an 
electronic terminal. 

(c) Exclusions from coverage . The term electronic fund 
transfer does not include: 

(1) Checks . Any transfer of funds originated by 
check, draft, or similar paper instrument; or any 
payment made by check, draft, or similar paper 
instrument at an electronic terminal. 

(2) Check guarantee or authorization . Any 
transfer of funds that guarantees payment or 
authorizes acceptance of a check, draft, or 
similar paper instrument but that does not 
directly result in a debit or credit to a consumer's 
account. 

(3) Wire or other similar transfers . Any transfer 
of funds through Fedwire or through a similar 
wire transfer system that is used primarily for 



REGE2 



2005 ACH RULES 



REGULATIONE 



transfers between financial institutions or 
between businesses. 

(4) Securities and commodities transfers . Any 
transfer of funds the primary purpose of which is 
the purchase or sale of a security or commodity, 
if the security or commodity is: 

(i) Regulated by the Securities and 

Exchange Commission or the 
Commodity Futures Trading 
Commission; 

(ii) Purchased or sold through a broker- 

dealer regulated by the Securities and 
Exchange Commission or through a 
futures commission merchant regulated 
by the Commodity Futures Trading 
Commission; or 

(iii) Held in book-entry form by a Federal 
Reserve Bank or federal agency. 

(5) Automatic transfers by account-holding 
institution . Any transfer of funds under an 
agreement between a consumer and a financial 
institution which provides that the institution will 
initiate individual transfers without a specific 
request from the consumer: 

(i) Between a consumer's accounts within 

the financial institution; 

(ii) From a consumer's account to an 

account of a member of the consumer's 
family held in the same financial 
institution; or 

(iii) Between a consumer's account and an 
account of the financial institution, 
except that these transfers remain 
subj ect to § 205 . 1 0(e) regarding 
compulsory use and sections 915 and 
916 of the act regarding civil and 
criminal liability. 

(6) Telephone-initiated transfers . Any transfer 
of funds that: 

(i) Is initiated by a telephone 

communication between a consumer 
and a financial institution making the 
transfer; and 

(ii) Does not take place under a telephone 

bill-payment or other written plan in 



which periodic or recurring transfers 
are contemplated. 

(7) Small institutions . Any preauthorized 
transfer to or from an account if the assets of the 
account-holding financial institution were $100 
million or less on the preceding December 3 1 . 
If assets of the account-holding institution 
subsequently exceed $100 million, the 
institution's exemption for preauthorized 
transfers terminates one year from the end of the 
calendar year in which the assets exceed $ 1 00 
million. Preauthorized transfers exempt under 
this paragraph remain subject to § 205.10(e) of 
Regulation E regarding compulsory use and 
sections 915 and 916 of the act regarding civil 
and criminal liability. 

§ 205.4 General disclosure requirements; jointly 
offered services. 

(a) (1) Form of disclosures . Disclosures required 
under this regulation shall be clear and readily 
understandable, in writing, and in a form the 
consumer may keep. A financial institution may 
use commonly accepted or readily 
understandable abbreviations in complying with 
the disclosure requirements of the regulation. 

(2) Foreign language disclosures . Disclosures 
required under this part may be made in a 
language other than English, provided that the 
disclosures are made available in English upon 
the consumer's request. 

(b) Additional information; disclosures required by other 
laws . A financial institution may include additional 
information and may combine disclosures required by 
other laws (such as the Truth in Lending Act (15 U.S.C. 
1601 et seq.) or the Truth in Savings Act (12 U.S.C. 4301 
et seq.)) with the disclosures required by this regulation. 




(c) Electronic communication . For rules governing the 
electronic delivery of disclosures, including the definition 
of electronic communication, see § 205.17. 

(d) Multiple accounts and account holders . 

(1) Multiple accounts . A financial institution 
may combine the required disclosures into a 
single statement for a consumer who holds more 
than one account at the institution. 

(2) Multiple account holders . For joint accounts 
held by two or more consumers, a financial 
institution need provide only one set of the 
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required disclosures and may provide them to 
any of the account holders. 

(eV Services offered jointly . Financial institutions that 
provide electronic fund transfer services jointly may 
contract among themselves to comply with the 
requirements that this regulation imposes on any or all of 
them. An institution need make only the disclosures 
required by §§205.7 and 205.8 that are within its 
knowledge and within the purview of its relationship with 
the consumer for whom it holds an account. 

§ 205.5 Issuance of access devices. 

(a) Solicited issuance . Except as provided in paragraph 

(b) of this section, a financial institution may issue an 
access device to a consumer only: 

(1) In response to an oral or written request for 
the device; or 

(2) As a renewal of, or in substitution for, an 
accepted access device whether issued by the 
institution or a successor. 

(b) Unsolicited issuance . A financial institution may 
distribute an access device to a consumer on an 
unsolicited basis if the access device is: 

(1) Not validated, meaning that the institution 
has not yet performed all the procedures that 
would enable a consumer to initiate an electronic 
fiandto 

(2) Accompanied by a clear explanation that the 
access device is not validated and how the 
consumer may dispose of it if validation is not 
desired; 

(3) Accompanied by the disclosures required by 
§ 205.7, of the consumer's rights and liabilities 
that will apply if the access device is validated; 
and 

(4) Validated only in response to the consumer's 
oral or written request for validation, after the 
institution has verified the consumer's identity by 
a reasonable means. 

§ 205.6 Liability of consumer for unauthorized 
transfers. 

(a) Conditions for liability . A consumer may be held 
liable, within the limitations described in paragraph (b) of 
this section, for an unauthorized electronic fund transfer 
involving the consumer's account only if the financial 



institution has provided the disclosures required by § 
205.7(b)(1), (2), and (3). If the unauthorized transfer 
involved an access device, it must be an accepted access 
device and the financial institution must have provided a 
means to identify the consumer to whom it was issued. 

.(b) Limitations on amount of liability . A consumer's 
liability for an unauthorized electronic fund transfer or a 
series of related unauthorized transfers shall be 
determined as follows: 

(1) Timely notice given . If the consumer notifies 
the financial institution within two business days 
after learning of the loss or theft of the access 
device, the consumer's liability shall not exceed 
the lesser of $50 or the amount of unauthorized 
transfers that occur before notice to the financial 
institution. 



(2) Timely notice not given . If the consumer 
fails to notify the financial institution within two 
business days after learning of the loss or theft of 
the access device, the consumer's liability shall 
not exceed the lesser of $500 or the sum of: 



(i) $50 or the amount of unauthorized 

transfers that occur within the two 
business days, whichever is less; and 

(ii) The amount of unauthorized transfers 

that occur after the close of two 
business days and before notice to the 
institution, provided the institution 
establishes that these transfers would 
not have occurred had the consumer 
notified the institution within that two- 
day period. 

(3) Periodic statement; timely notice not given . 
A consumer must report an unauthorized 
electronic fund transfer that appears on a 
periodic statement within 60 days of the 
financial institution's transmittal of the statement 
to avoid liability for subsequent transfers. If the 
consumer fails to do so, the consumer's liability 
shall not exceed the amount of the unauthorized 
transfers that occur after the close of the 60 days 
and before notice to the institution, and that the 
institution establishes would not have occurred 
had the consumer notified the institution within 
the 60-day period. When an access device is 
involved in me unauthorized transfer, the 
consumer may be liable for other amounts set 
forth in paragraphs (b)(1) or (b)(2) of this 
section, as applicable. 
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(4) Extension of time limits . If the consumer's 
delay in notifying the financial institution was 
due to extenuating circumstances, the institution 
shall extend the times specified above to a 
reasonable period. 

(5} Notice to financial institution . 



(i) 



(ii) 



(hi) 



Notice to a financial institution is given 
when a consumer takes steps 
reasonably necessary to provide the 
institution with the pertinent 
information, whether or not a particular 
employee or agent of the institution 
actually receives the information. 

The consumer may notify the 
institution in person, by telephone, or 
in writing. 

Written notice is considered given at 
the time the consumer mails the notice 
or delivers it for transmission to the 
institution by any other usual means. 
Notice may be considered 
constructively given when the 
institution becomes aware of 
circumstances leading to the reasonable 
belief that an unauthorized transfer to 
or from the consumer's account has 
been or may be made. 



(6) Liability under state law or agreement . If 
state law or an agreement between the consumer 
and the financial institution imposes less liability 
than is provided by this section, the consumer's 
liability shall not exceed the amount imposed 
under the state law or agreement. 



§ 205.7 Initial disclosures. 

(a) Timing of disclosures . A financial institution shall 
make the disclosures required by this section at the time 
a consumer contracts for an electronic fund transfer 
service or before the first electronic fund transfer is made 
involving the consumer's account. 

fb^i Content of disclosures . A financial institution shall 
provide the following disclosures, as applicable: 

(1) Liability of consumer . A summary of the 
consumer's liability, under §205.6 or under 
state or other applicable law or agreement, for 
unauthorized electronic fund transfers. 



(2) Telephone number and address . The 
telephone number and address of the person or 
office to be notified when the consumer believes 
that an unauthorized electronic fund transfer has 
been or may be made. 

GV Business days . The financial institution's 
business days. 

(4) Types of transfers: limitations . The type of 
electronic fund transfers that the consumer may 
make and any limitations on the frequency and 
dollar amount of transfers. Details of the 
limitations need not be disclosed if 
confidentiality is essential to maintain the 
security of the electronic fund transfer system. 

(5) Fees . Any fees imposed by the financial 
institution for electronic fund transfers or for the 
right to make transfers. 

(6) Documentation . A summary of the 
consumer's right to receipts and periodic 
statements, as provided in § 205.9, and notices 
regarding preauthorized transfers as provided in 
§§205.10(a), and 205. 10(d). 

(7) Stop payment . A summary of the consumer's 
right to stop payment of a preauthorized 
electronic fund transfer and the procedure for 
placing a stop-payment order, as provided in § 
205.10(c). 

(8) Liability of institution . A summary of the 
financial institution's liability to the consumer 
under section 910 of the act for failure to make 
or to stop certain transfers. 

(9) Confidentiality . The circumstances under 
which, in the ordinary course of business, the 
financial institution may provide information 
concerning the consumer's account to third 
parties. 

(10) Error resolution . A notice that is 
substantially similar to Model Form A-3 as set 
out in Appendix A to this part concerning error 
resolution. 

YllT ATM fees . A notice that a fee may be 
imposed by an automated teller machine 
operator as defined in § 205.16(a)(1), when the 
consumer initiates an electronic fund transfer or 
makes a balance inquiry, and by any network 
used to complete the transaction. 
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§ 205.8 
notice. 



Change in terms notice; error resolution 



(a) Change in terms notice . 

(1) Prior notice required . A financial institution 
shall mail or deliver a written notice to the 
consumer, at least 21 days before the effective 
date, of any change in a term or condition 
required to be disclosed under § 205.7(b) if the 
change would result in: 

(i) Increased fees for the consumer; 

(ii) Increased liability for the consumer; 



(Hi) Fewer types of available electronic 
fund transfers; or 

(iv) Stricter limitations on the frequency or 
dollar amount of transfers. 



(2) Prior notice exception . A financial 
institution need not give prior notice if an 
immediate change in terms or conditions is 
necessary to maintain or restore the security of 
an account or an electronic fund transfer system. 
If the institution makes such a change permanent 
and disclosure would not jeopardize the security 
of the account or system, the institution shall 
notify the consumer in writing on or with the 
next regularly scheduled periodic statement or 
within 30 days of making the change permanent. 

(b) Error resolution notice . For accounts to or from which 
electronic fund transfers can be made, a financial 
institution shall mail or deliver to the consumer, at least 
once each calendar year, an error resolution notice 
substantially similar to the model form set forth in 
Appendix A of mis part (Model Form A-3). 
Alternatively, an institution may include an abbreviated 
notice substantially similar to the model form error 
resolution notice set forth in Appendix A of this part 
(Model Form A-3), on or with each periodic statement 
required by § 205.9(b). 

§ 205.9 Receipts at electronic terminals; periodic 
statements. 

(a) Receipts at electronic terminals . A financial institution 
shall make a receipt available to a consumer at the time 
the consumer initiates an electronic fund transfer at an 
electronic terminal. The receipt shall set forth the 
following information, as applicable: 



(1) Amount . The amount of the transfer. A 
transaction fee may be included in this amount, 
provided the amount of the fee is disclosed on 
the receipt and displayed on or at the terminal. 



(2) Date , 
transfer. 



The date the consumer initiates the 



(3) JY££v The type of transfer and the type of 
the consumer's account(s) to or from which 
funds are transferred. The type of account may 
be omitted if the access device used is able to 
access only one account at mat terminal 

(4) Identification . A number or code that 
identifies the consumer's account or accounts, or 
the access device used to initiate the transfer. 
The number or code need not exceed four digits 

or letters to comply with the requirements of this 
paragraph. 

(5) Terminal location . The location of the 
terminal where the transfer is initiated, or an 
identification such as a code or terminal number. 
Except in limited circumstances where all 
terminals are located in the same city or state, if 
the location is disclosed, it shall include the city 
and state or foreign country and one of the 
following: 

(i) The street address; or 

(ii) A generally accepted name for the 

specific location; or 

(Hi) The name of the owner or operator of 
the terminal if other than the account- 
holding institution. 

(6) Third party transfer . The name of any third 
party to or from whom funds are transferred. 

(b) Periodic statements . For an account to or from which 
electronic fund transfers can be made, a financial 
institution shall send a periodic statement for each 
monthly cycle in which an electronic fund transfer has 
occurred; and shall send a periodic statement at least 
quarterly if no transfer has occurred. The statement shall 
set forth the following information, as applicable: 



( 1 ) Transaction information . For each electronic 
fund transfer occurring during the cycle: 



REGE6 



2005 ACH RULES 



REGULATION E 



(i) 



The amount of the transfer; 



(ii) The date the transfer was credited or 
debited to the consumer's account; 



(hi) 



(iv) 



(v) 



The type of transfer and type of 
account to or from which funds were 
transferred; 

For a transfer initiated by the consumer 
at an electronic terminal (except for a 
deposit of cash or a check, draft, or 
similar paper instrument), the terminal 
location described in paragraph (a)(5) 
ofthis section; and 

The name of any third party to or from 
whom funds were transferred. 



(2) Account number , 
account. 



The number of the 



(3) Fees . The amount of any fees assessed 
against the account during the statement period 
for electronic fund transfers, for the right to 
make transfers, or for account maintenance. 

(4) Account balances . The balance in the 
account at the beginning and at the close of the 
statement period. 

(5) Address and telephone number for inquiries . 
The address and telephone number to be used for 
inquiries or notice of errors, preceded by "Direct 
inquiries to" or similar language. The address 
and telephone number provided on an error 
resolution notice under § 205.8(b) given on or 
with the statement satisfies this requirement. 

(6) Telephone number for preauthorized 
transfers . A telephone number the consumer 
may call to ascertain whether preauthorized 
transfers to the consumer's account have 
occurred, if the financial institution uses the 
telephone-notice option under § 
205.10(a)(l)(iii). 

(c) Exceptions to the periodic statement requirement for 
certain accounts . 

(IV Preauthorized transfers to accounts . For 
accounts that may be accessed only by 
preauthorized transfers to the account the 
following rules apply: 



(i) Passbook accounts . For passbook 

accounts, the financial institution need 
not provide a periodic statement if the 
institution updates the passbook upon 
presentation or enters on a separate 
document the amount and date of each 
electronic fund transfer since the 
passbook was last presented. 

(ii) Other accounts . For accounts other 

than passbook accounts, the financial 
mstimtion^ must send a periodic 
statement at least quarterly. 

(2> Intra-institutional transfers . For an electronic 
fund transfer initiated by the consumer between 
two accounts of the consumer in the same 
institution, documenting the transfer on a 
periodic statement for one of the two accounts 
satisfies the periodic statement requirement. 

(3) Relationship between paragraphs (c)(1) and 
(c)(2) of this section . An account that is 
accessed by preauthorized transfers to the 
account described in paragraph (c)(1) of this 
section and by intra-institutional transfers 
described in paragraph (c)(2) ofthis section, but 
by no other type of electronic fund transfers, 
qualities for the exceptions provided by 
paragraph (c)(1) of this section. 



(d) Documentation for foreign-initiated transfers . The 
failure by a financial institution to provide a terminal 
receipt for an electronic fund transfer or to document the 
transfer on a periodic statement does not violate this 
regulation if: 

(1) The transfer is not initiated within a state; 
and 

(2) The financial institution treats an inquiry for 
clarification or documentation as a notice of 
error in accordance with § 205.11. 

§ 205.10 Preauthorized transfers. 

(a) Preauthorized transfers to consumer's account . 

(1) Notice by financial institution . When a 
person initiates preauthorized electronic fund 
transfers to a consumer's account at least once 
every 60 days, the account-holding financial 
institution shall provide notice to the consumer 

by: 
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(i) Positive notice . Providing oral or 

written notice of the transfer within two 
business days after the transfer occurs; 
or 

(ii) Negative notice . Providing oral or 

written notice, within two business 
days after the date on which the 
transfer was scheduled to occur, that 
the transfer did not occur; or 

(in) Readily-available telephone line . 
Providing a readily available telephone 
line that the consumer may call to 
determine whether the transfer 
occurred and disclosing the telephone 
number on the initial disclosure of 
account terms and on each periodic 
statement. 

(2) Notice by payor . A financial institution need 
not provide notice of a transfer if the payor gives 
me consumer positive notice mat the transfer has 
been initiated. 

(3V Crediting / A financial institution that 
receives a preauthorized transfer of the type 
described in paragraph (a)(1) of this section shall 
credit the amount of the transfer as of the date 
the funds for the transfer are received. 

(b) Written authorization for preauthorized transfers from 
consumer's account . Preauthorized electronic fund 
transfers from a consumer's account may be authorized 
only by a writing signed or similarly authenticated by the 
consumer. The person that obtains the authorization shall 
provide a copy to the consumer. 

(c) Consumer's right to stop payment . 

(1) Notice. A consumer may stop payment of a 
preauthorized electronic fund transfer from the 
consumer's account by notifying the financial 
institution orally or in writing at least three 
business days before the scheduled date of the 
transfer. 



to be binding after 14 days if the consumer fails 
to provide the required written coru%mation. 

(d) Notice of transfers varying in amount . 

(1) Notice . When a preauthorized electronic 
fund transfer from the consumer's account will 
vary in amount from the previous transfer under 
the same authorization or from the preauthorized 
amount, the designated payee or the financial 
institution shall send the consumer written notice 
of the amount and date of the transfer at least 10 
days before the scheduled date of transfer. 

(2) Range . The designated payee or the 
institution shall inform the consumer of the right 
to receive notice of all varying transfers, but may 
give the consumer the option of receiving notice 
only when a transfer falls outside a specified 
range of amounts or only when a transfer differs 
from the most recent transfer by more than an 
agreed-upon amount. 

(e) Compulsory use . 

0) £l£dit. No financial institution or other 
person may condition an extension of credit to a 
consumer on the consumer's repayment by 
preauthorized electronic fund transfers, except 
for credit extended under an overdraft credit 
plan or extended to maintain a specified 
minimum balance in the consumer's account. 

(2) Employment or government benefit . No 
financial institution or other person may require 
a consumer to establish an account for receipt of 
electronic fund transfers with a particular 
institution as a condition of employment or 
receipt of a government benefit. 

§ 205.1 1 Procedures for resolving errors. 

(a) Definition of error . 

(1) Types of transfers or inquiries covered . The 
term "error" means: 



(2) Written confirmation . The financial 
institution may require the consumer to give 
written confirmation of a stop-payment order 
within 14 days of an oral notification. An 
institution that requires written confirmation 
shall inform the consumer of the requirement 
and provide the address where confirmation 
must be sent when the consumer gives the oral 
notification. An oral stop-payment order ceases 



(i) An unauthorized electronic fund 

transfer; 

(ii) An incorrect electronic fund transfer to 

or from the consumer's account; 

(iii) The omission of an electronic fund 
transfer from a periodic statement; 
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(iv) 



(v) 



(vi) 



(vii) 



A computational or bookkeeping error 
made by the financial institution 
relating to an electronic fund transfer; 

The consumer's receipt of an incorrect 
amount of money from an electronic 
terminal; 

An electronic fund transfer not 
identified in accordance with §§ 205.9 
or 205.10(a) of Regulation E; or 
The consumer's request for 
documentation required by §§ 205.9 or 
205.10(a) of Regulation E or for 
additional information or clarification 
concerning an electronic fund transfer, 
including a request the consumer 
makes to determine whether an error 
exists under paragraphs (a)(l)(i) 
through (vi) of this section. 



(2) Types of inquiries not covered . The term 
"error" does not include: 

(i) A routine inquiry about the consumer's 

account balance; 

(ii) A request for information for tax or 

other recordkeeping purposes; or 

(in) A request for duplicate copies of 
documentation. 

(b) Notice of error from consumer . 

(1) Timing; contents . A financial institution 
shall comply with the requirements of this 
section with respect to any oral or written notice 
of error from the consumer that: 

(i) Is received by the institution no later 

than 60 days after the institution sends 
the periodic statement or provides the 
passbook documentation, required by § 
205.9, on which the alleged error is 
first reflected; 

(ii) Enables the institution to identify the 

consumer's name and account number; 

■'■v.'- and 

(iii) Indicates why the consumer believes an 
error exists and includes to the extent 
possible the type, date, and amount of 
the error, except for reque sts described 
in paragraph (a)(l)(vii) of this section. 



(2) Written confirmation . A financial institution 
may require the consumer to give written 
confirmation of an error within 1 business days 
of an oral notice. An institution that requires 
written confirmation shall inform the consumer 
of the requirement and provide the address 
where confirmation must be sent when the 
consumer gives the oral notification. 

(3) Request for documentation or clarifications . 
When a notice of error is based on 
documentation or clarification that the consumer 
requested under paragraph (a)(l)(vii) of this 
section, the consumer's notice of error is timely 
if received by the financial institution no later 
than 60 days after the institution sends the 
information requested. 

(c) Time limits and extent of investigation . 

( 1 ) Ten-day period . A financial institution shall 
investigate promptly and, except as otherwise 
provided in this paragraph, shall determine 
whether an error occurred within 10 business 
days of receiving a notice of error. The 
institution shall report the results to the 
consumer within three business days after 
completing its investigation. The institution 
shall correct the error within one business day 
after determining that an error occurred. 

(2) Fortv-five day period . If the financial 
institution is unable to complete its investigation 
within 10 business days, the institution may take 
up to 45 days from receipt of a notice of error to 
investigate and determine whether an error 
occurred, provided the institution does the 
following: 

(i) Provisionally credits the consumer's 

account in the amount of the alleged 
error (including interest where 
applicable) within 10 business days of 
receiving the error notice. If the 
financial institution has a reasonable 
basis for believing that an unauthorized 
electronic fund transfer has occurred 
and the institution has satisfied the 
requirements of § 205.6(a) of 
Regulation E, the institution may 
withhold a maximum of $50 from the 
amount credited. An institution need 
not provisionally credit the consumer's 
account if: 
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(") 



(A) The institution requires but does 
not receive written confirmation within 
10 business days of an oral notice of 
error; or 

(B) The alleged error involves an 
account that is subject to Regulation T 
(Securities Credit by Brokers and 
Dealers, 12 CFR part 220); 

Informs the consumer, within two 
business days after the provisional 
crediting, of the amount and date of 
the provisional crediting and gives the 
consumer full use of the funds during 
the investigation; 



(iii) 



(iv) 



Corrects the error, if any, within one 
business day after determining that an 
error occurred; and 

Reports the results to the consumer 
within three business days after 
completing its investigation (including, 
if applicable, notice that a provisional 
credit has been made final). 



(3) Extension of time periods . The time periods 
in paragraphs (c)(1) and (c)(2) are extended as 
follows: 



(0 



.(ii) 



The applicable time is 20 business days 
in place of 10 business days under 
paragraphs (c)(1) and (c)(2) if the 
notice of error involves an electronic 
fund transfer to or from the account 
within 30 days after the first deposit to 
the account was made . 

The applicable time is 90 days in place 
of 45 days under paragraph (c)(2), for 
completing an investigation, if a notice 
of error involves an electronic fund 
transfer that: 



(A) Was not initiated within a state; 



(B) Resulted from a point-of-sale debit 
card transaction; or 

(C) Occurred within 30 days after the 
first deposit to the account was made. 

(4) Investigation , With the exception of 
transfers covered by § 205.14 of Regulation E, 



a financial institution's review of its own records 
regarding an alleged error satisfies the 
requirements of this section if: 

(i) The alleged error concerns a transfer to 

or from a third party; and 

(ii) There is no agreement between the 

institution and the third party for the 
type of electronic fund transfer 
involved. 

(d) Procedures if financial institution determines no error 
or different error occurred . In addition to following the 
procedures specified in paragraph (c) of this section, the 
financial institution shall follow the procedures set forth 
in this paragraph if it determines that no error occurred or 
that an error occurred in a manner or amount different 
from that described by the consumer: 

(1) Written explanation . The institution's report 
of the results of its investigation shall include a 
written explanation of the institution's findings 
and shall note the consumer's right to request the 
documents that the institution relied on in 
making its determination. Upon request, the 
institution shall promptly provide copies of the 
documents. 

(2) Debiting provisional credit . Upon debiting 
a provisionally credited amount, the financial 
institution shall: 



(0 



(ii) 



Notify the consumer of the date and 
amount of the debiting; 



Notify the consumer that the institution 
will honor checks, drafts, or similar 
instruments payable to third parties and 
preauthorized transfers from the 
consumer's account (without charge to 
the consumer as a result of an 
overdraft) for five business days after 
the notification. The institution shall 
honor items as specified in the notice, 
but need honor only items that it would 
have paid if the provisionally credited 
funds had not been debited. 



(e) Reassertion of error . A financial institution that has 
fully complied with the error resolution requirements has 
no further responsibilities under this section should the 
consumer later reassert the same error, except in the case 
of an error asserted by the consumer following receipt of 
information provided under paragraph (a)( 1 )( vii) of this 
section. 
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§ 205.12 Relation to other laws. 

(2l) Relation to Truth in Lending . 

(1) The Electronic Fund Transfer Act and 
Regulation E govern: 

(i) The addition to an accepted credit card, 

as defined in Regulation Z (12 CFR 
226.12(a)(2), footnote 21), of the 
capability to initiate electronic fund 
transfers; 

(ii) The issuance of an access device that 

permits credit extensions (under a 
preexisting agreement between a 
consumer and a financial institution) 
only when the consumer's account is 
overdrawn or to maintain a specified 
minimum balance in the consumer's 
account; and 

(hi) A consumer's liability for an 
unauthorized electronic fund transfer 
and the investigation of errors 
involving an extension of credit that 
occurs under an agreement between the 
consumer and a financial institution to 
extend credit when the consumer's 
account is overdrawn or to maintain a 
specified minimum balance in the 
consumer's account. 

(2) The Truth in Lending Act and Regulation Z, 
which prohibit the unsolicited issuance of credit 
cards, govern: 

(i) The addition of a credit feature to an 

accepted access device; and 

(ii) Except as provided in paragraph 

(a)(1)(h) of this section, the issuance of 
a credit card that is also an access 
device. 

(b) Preemption of inconsistent state laws . 

(1) Inconsistent requirements . The Board shall 
determine, upon its own motion or upon the 
request of a state, financial institution, or other 
interested party, whether the act and this 
regulation preempt state law relating to 
electronic fund transfers. Only state laws that 
are inconsistent with the act and this regulation 
are preempted and then only to the extent of the 
inconsistency. A state law is not inconsistent 



with the act and this regulation if it is more 
protective of consumers. 

Y2Y Standards for determination . State law is 
inconsistent with the requirements of the act and 
this regulation if it: 

(i) Requires or permits a practice or act 

prohibited by the federal law; 

(ii) Provides for consumer liability for 

unauthorized electronic fund transfers 
that exceeds the limits imposed by the 
federal law; 

(iii) Allows longer time periods than the 
federal law for investigating and 
correcting alleged errors, or does not 
require the financial institution to credit 
the consumer's account during an error 
investigation in accordance with § 
205.1 l(c)(2)(i) of Regulation E; or 

(iv) Requires initial disclosures, periodic 
statements, or receipts that are different 
in content from those required by the 
federal law except to the extent that the 
disclosures relate to consumer rights 
granted by the state law and not by the 
federal law. 



(c) State exemptions . 



(1) General rule . Any state may apply for an 
exemption from the requirements of the act or 
this regulation for any class of electronic fund 
transfers within the state. The Board shall grant 
an exemption if it determines that: 

(i) Under state law the class of electronic 

fund transfers is subject to 
requirements substantially similar to 
those imposed by the federal law; and 

(ii) There is adequate provision for state 

enforcement. 

(2) Exception . To assure that the federal and 
state courts continue to have concurrent 
jurisdiction, and to aid in implementing the act: 

(i) No exemption shall extend to the civil 

liability provisions of section 915 of 
the act; and 
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§205.13 
retention. 



When the Board grants an exemption, 
the state law requirements shall 
constitute the requirements of the 
federal law for purposes of section 915 
of the act, except for state law 
requirements not imposed by the 
federal law. 

Administrative enforcement; record 




(a) Enforcement bv federal agencies . Compliance with 
Regulation E is enforced by the agencies listed in 
Appendix B of this part. 

(b) Record retention . 

(1) Any person subject to the act and this 
regulation shall retain evidence of compliance 
with the requirements imposed by the act and 
this regulation for a period of not less than two 
years from the date disclosures are required to be 
made or action is required to be taken. 

(2) Any person subject to the act and this v 
regulation having actual notice that it is the 
subject of an investigation or an enforcement 
proceeding by its enforcement agency, or having 
been served with notice of an action filed under 
sections 910, 915, or 916(a) of the act, shall 
retain the records that pertain to the 
investigation, action, or proceeding until final 
disposition of the matter unless an earlier time is 
allowed by court or agency order. 

§ 205.14 Electronic fund transfer service provider not 
holding consumer's account. 

(a) Provider of electronic fund transfer service . A person 
that provides an electronic fund transfer service to a 
consumer but that does not hold the consumer's account is 
subject to all requirements of this regulation if the person: 

(1) Issues a debit card (or other access device) 
that the consumer can use to access the 
consumer's account held by a financial 
institution; and 

(2) Has no agreement with the account-holding 
institution regarding such access. 



(b) Compliance by service provider . In addition to the 
requirements generally applicable under Regulation E, the 
service provider shall comply with the following special 
rules: 



( 1 ) Disclosures and documentation . The service 
provider shall give the disclosures and 
documentation required by §§ 205.7, 205.8, and 
205.9 of Regulation E that are within the 
purview of its relationship with the consumer. 
The service provider need not furnish the 
periodic statement required by § 205.9(b) of 
Regulation E if the following conditions are met: 



(0 



(ii) 



(hi) 



"fly)'- 



(v) 



The debit card (or other access device) 
issued to the consumer bears the 
service provider's name and an address 
or telephone number for making 
inquiries or giving notice of error; 

The consumer receives a notice 
concerning use of the debit card that is 
substantially similar to the notice 
contained in Appendix A of this part; 



The consumer receives, on or with the 
receipts required by § 205.9(a) of 
Regulation E, the address and 
telephone number to be used for an 
inquiry, to give notice of an error, or to 
report the loss or theft of the debit card; 

The service provider transmits to the 
account-holding institution the 
information specified in § 205.9(b)(1) 
of Regulation E, in the format 
prescribed by the automated 
clearinghouse system used to clear the 
fund transfers; 

The service provider extends the time 
period for notice of loss or theft of a 
debit card, set forth in § 205.6(b)(1) 
and (2) of Regulation E, from two 
business days to four business days 
after the consumer learns of the loss or 
theft; and extends the time periods for 
reporting unauthorized transfers or 
errors, set forth in §§ 205.6(b)(3) and 
205.1 1 (b)( 1 )(i) of Regulation E, from 
60 days to 90 days following the 
transmittal of a periodic statement by 
the account-holding institution. 



(2) Error resolution . 

(i) The service provider shall extend by a 

reasonable time the period in which 
notice of an error must be received, 
specified in § 205.1 l(b)(l)(i) of 
Regulation E, if a delay resulted from 
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an initial attempt by the consumer to 
notify the account-holding institution. 

(ii) The service provider shall disclose to 

the consumer the date on which it 
initiates a transfer to effect a 
provisional credit in accordance with § 
205.1 l(c)(2)(ii) of Regulation E. 

(hi) If the service provider determines an 
error occurred, it shall transfer funds to 
or from the consumer's account, in the 
appropriate amount and within the 
applicable time period, in accordance 
with § 205.1 l(c)(2)(i) of Regulation E. 

(iv) If funds were provisionally credited 
and the service provider determines no 
error occurred, it may reverse the 
credit. The service provider shall 
notify the account-holding institution of 
the period during which the account- 
holding institution must honor debits to 
the account in accordance with § 
205.1 1(d)(2)(h) of Regulation E. If ah 
overdraft results, the service provider 
shall promptly reimburse the account- 
holding institution in the amount of the 
overdraft. 

(c) Compliance by account-holding institution . The 
account-holding institution need not comply with the 
requirements of the act and this regulation with respect to 
electronic fund transfers initiated through the service 
provider except as follows: 

(1) Documentation . The account-holding 
institution shall provide a periodic statement that 
describes each electronic fund transfer initiated 
by the consumer with the access device issued by 
the service provider. The account-holding 
institution has no liability for the failure to 
comply with this requirement if the service 
provider did not provide the necessary 
information; and 

(2) Error resolution. Upon request, the account- 
holding institution shall provide information or 
copies of documents needed by the service 
provider to investigate errors or to furnish copies 
of documents to the consumer. The account- 
holding institution shall also honor debits to the 
account in accordance with § 205.1 1(d)(2)(h) of 
Regulation E. 



§20515 
benefits. 



Electronic fund transfer of government 



(a) Government agency subject to regulation . 

(1) A government agency is deemed to be a 
financial institution for purposes of the act and 
this part if directly or indirectly it issues an 
access device to a consumer for use in initiating 
an electronic fund transfer of government 
benefits from an account, other than needs-tested 
benefits in a program established under state or 
local law or administered by a state or local 
agency. The agency shall comply with all 
applicable requirements of the act and this part, 
except as provided in this section. 



(2) For purposes of this section, the term account 
means an account established by a government 
agency for distributing government benefits to a 
consumer electronically, such as through 
automated teller machines or point-of-sale 
terminals, but does not include an account for 
distributing needs-tested benefits in a program 
established under state or local law or 
administered by a state or local agency. 

.(b) Issuance of access devices . For purposes of this 
section, a consumer is deemed to request an access device 
when the consumer applies for government benefits that 
the agency disburses or will disburse by means of an 
electronic fund transfer. The agency shall verify the 
identity of the consumer receiving the device by 
reasonable means before the device is activated. 

(c) Alternative to periodic statement . A government 
agency need not furnish the periodic statement required by 
§ 205.9(b) if the agency makes available to the consumer: 

(1) The consumer's account balance, through a 
readily available telephone line and at a terminal 
(such as by providing balance information at a 
balance-inquiry terminal or providing it, 
routinely or upon request, on a terminal receipt 
at the time of an electronic fund transfer); and 

(2) A written history of the consumer's account 
transactions that is provided promptly in 
response to an oral or written request and that 
covers at least 60 days preceding the date of a 
request by the consumer. 

(d) Modified requirements . A government agency that 
does not furnish periodic statements, in accordance with 
paragraph (c) of this section, shall comply with the 
following special rules: 
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(1) Initial disclosures . The agency shall modify 
the disclosures under § 205.7(b) by disclosing: 

(i) Account balance . The means by which 

the consumer may obtain information 
concerning the account balance, 
including a telephone number. The 
agency provides a notice substantially 
similar to the notice contained in 
paragraph A-5 in Appendix A of this 
part. 

(ii) Written account history . A summary of 

the consumer's right to receive a 
written account history upon request, in 
place of the periodic statement required 
by § 205.7(b)(6), and the telephone 
number to call to request an account 
history. This disclosure may be made 
by providing a notice substantially 
similar to the notice contained in 
paragraph A-5 in Appendix A of this 
part. 




(Hi) Error resolution . A notice concerning 
error resolution that is substantially 
similar to the notice contained in 
paragraph A-5 in Appendix A of this 
part, in place of the notice required by 
§205.7(b)(10). 

(2) Annual error resolution notice . The agency 
shall provide an annual notice concerning error 
resolution that is substantially similar to the 
notice contained in paragraph A-5 in appendix 
A, in place of the notice required by § 205.8(b). 

(3) Limitations on liability . For purposes of § 
205.6(b)(3), regarding a 60-day period for 
reporting any unauthorized transfer that appears 
on a periodic statement, the 60-day period shall 
begin with transmittal of a written account 
history or other account information provided to 
the consumer under paragraph (c) of this section. 

(4) Error resolution . The agency shall comply 
with the requirements of § 205.11 in response to 
an oral or written notice of an error from the 
consumer that is received no later than 60 days 
after the consumer obtains the written account 
history or other account information, under 
paragraph (c) of this section, in which the error 
is first reflected. 



§ 205.16 Disclosures at automated teller machines. 

(a) Definition . Automated teller machine operator means 
any person that operates an automated teller machine at 
which a consumer initiates an electronic fund transfer or 
a balance inquiry and that does not hold the account to or 
from which the transfer is made, or about which an 
inquiry is made. 

(b) General . An automated teller machine operator that 
imposes a fee on a consumer for initiating an electronic 
fund transfer or a balance inquiry shall: 



(1) Provide notice that a fee will be imposed for 
providing electronic fund transfer services or a 
balance inquiry; and 



(2) Disclose the amount of the fee. 

(c) Notice requirement . An automated teller machine 
operator must comply with the following: 



(1) On the machine .Post the notice required by 
paragraph (b)(1) of this section in a prominent 
and conspicuous location on or at the automated 
teller machine; and 



(2) Screen or paper notice . Provide the notice 
required by paragraphs (b)(1) and (b)(2) of this 
section either by showing it on the screen of the 
automated teller machine or by providing it on 
paper, before the consumer is committed to 
paying a fee. 

(d) Temporary exemption . Through December 3 1, 2004, 
the notice requirement in paragraph (c)(2) of this section 
does not apply to any automated teller machine that lacks 
the technical capability to provide such information. 

(e) Imposition of fee . An automated teller machine 
operator may impose a fee on a consumer for initiating an 
electronic fund transfer or a balance inquiry only if 

(1) The consumer is provided the notices 
required under paragraph (c) of this section, and 

(2) The consumer elects to continue the 
transaction or inquiry after receiving such 
notices. 

§ 205.17 Requirements for electronic communication. 

(a) Definition . Electronic communication means a 
message transmitted electronically between a financial 
institution and a consumer in a format that allows visual 
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text to be displayed on equipment, for example, a personal 
computer monitor. 

(b) General rule . In accordance with the Electronic 
Signatures in Global and National Commerce Act (the E- 
Sign Act), 15 U.S.C. § 7001 et seq ., and the rules of this 
part, a financial institution may provide by electronic 
communication any disclosure required by this part to be 
in writing. 



(c) Address or location to receive 



electronic 
communication . A financial institution that uses 
electronic communication to provide disclosures required 
by this part shall: 

(1) Send the disclosure to the consumer's 
electronic address; or 

(2) Make the disclosure available at another 
location such as an Internet web site; and 

(i) Alert the consumer of the disclosure's 

availability by sending a notice to the 
consumer's electronic address (or to a 
postal address, at the financial 
institution's option). The notice shall 
identify the account involved and the 
address of the Internet web site or other 
location where the disclosure is 
available; and 

(ii) Make the disclosure available for at 

least 90 days from the date the 
disclosure first becomes available or 
from the date of the notice alerting the 
consumer of the disclosure, whichever 
comes later. 

(d) Redelivery . When a disclosure provided by electronic 
communication is returned to a financial institution 
undelivered, the financial institution shall take reasonable 
steps to attempt redelivery using information in its files. 

(e) Persons other than financial institutions . Persons other 
than a financial institution that are required to comply 
with this part may use electronic communication in 
accordance with the requirements of §205.17, as 
applicable. 



Appendices A and B are revised and Appendix C is added 
to read as follows: 

APPENDIX A TO PART 205-Model Disclosure 
Clauses and Forms 

A-l MODEL GLAUSES FOR UNSOLICITED 

ISSUANCE (§ 205.5(b)(2)) 



A-2--MODEL CLAUSES 
DISCLOSURES (§ 205.7(b)) 



FOR INITIAL 



A-3 -MODEL FORMS FOR ERROR RESOLUTION 
NOTICE (§§ 205.7(b)(10) and 205.8(b)) 



A-4 -MODEL FORM FOR SERVICE-PROVIDING 
INSTITUTIONS (§ 205.14(b)(l)(ii)) 

A 5--MODEL FORMS FOR GOVERNMENT 
AGENCIES (§ 205.15(d)(1) and (2)) A-l -MODEL 
CLAUSES FOR UNSOLICITED ISSUANCE (§ 
205.5(b)(2)) 

a) Accounts using cards . You cannot use the enclosed 
card to transfer money into or out of your account until we 
have validated it. If you do not want to use the card, 
please (destroy it at once by cutting it in half). 

[Financial institution may add validation 
instructions here.] 

(b) Accounts using codes . You cannot use the enclosed 
code to transfer money into or out of your account until 
we have validated it. If you do not want to use the code, 
please (destroy this notice at once). 

[Financial institution may add validation 
instructions here.] 




A-2-MODEL CLAUSES 
DISCLOSURES (§ 205.7(b)) 



FOR INITIAL 



(a) Consumer Liability (§ 205.7(b¥l)) . (Tell us AT 
ONCE if you believe your [card] [code] has been lost or 
stolen. Telephoning is the best way of keeping your 
possible losses down. You could lose all the money in 
your account (plus your maximum overdraft line of 
credit). If you tell us within 2 business days, you can lose 
no more than $50 if someone used your [card][code] 
without your permission. (If you believe your [card] 
[code] has been lost or stolen, and you tell us within 2 
business days after you learn of the loss or theft, you can 
lose no more than $50 if someone used your [card] [code] 
without your permission.) 



REG E 15 



'.REGULATION E: 



2005 ACH RULES 



If you do NOT tell us within 2 business days after you 
learn of the loss or theft of your [card] [code], and we can 
prove we could have stopped someone from using your 
[card] [code] without your permission if you had told us, 
you could lose as much as $500. 

Also, if your statement shows transfers that you did not 
make, tell us at once. Ifyou do not tell us within 60 days 
after the statement was mailed to you, you may not get 
back any money you lost after the 60 days if we can prove 
that we could have stopped someone from taking the 
money if you had told us in time. 

If a good reason (such as a long trip or a hospital stay) 
kept you from telling us, we will extend the time periods. 

( b ) Contact in event of unauthorized transfer ■'(( ■ 
205.7(b)(2)). If you believe your [card] [code] has been 
lost or stolen or that someone has transferred or may 
transfer money from your account without your 
permission, call: 

[Telephone number] 
or write: 

[Name of person or office to be notified] 
[Address] 

(c) Business davs (g 205.7(h)p)) Fnr piirrmcpc ^f th™* 
disclosures, our business days are (Monday through 
Friday) (Monday through Saturday) (any day including 
Saturdays and Sundays). Holidays are (not) included. 

( d ) Transfer types and limitations ($205. 7rbV4)) . 

(1) Account access . You may use your 
[card][code] to: 

(i) Withdraw cash from your [checking] 

[or] [savings] account. 

(ii) Make deposits to your [checking] [or] 

[savings] account 

(iii) Transfer funds between your checking 
and savings accounts whenever you 
request. 

(iv) Pay for purchases at places that have 
agreed to accept the [card] [code]. 

(v) Pay bills directly [by telephone] from 

your [checking] [or] [savings] account 
in the amounts and on the days you 
request. 



Some of these services may not be available at 
all terminals. 

(2) Limitations on frequency of transfers . 

(i) You may make only [insert number, 

e.g., 3] cash withdrawals from our 
terminals each [insert time period, e.g., 

week], 

(ii) You can use your telephone 

bill-payment service to pay [insert 
number] bills each [insert time period] 
[telephone call]. 

(iii) You can use our point-of-sale transfer 
service for [insert number] transactions 
each [insert time period]. 

(iv) For security reasons, there are limits on 
the number of transfers you can make 
using our [terminals] [telephone 
bill-payment service] [point-of-sale 
transfer service]. 

(3) Limitations on dollar amounts of transfers. 



(0 



(ii) 



You may withdraw up to [insert dollar 
amount] from our terminals each [insert 
time period] time you use the [card] 
[code]. 

You may buy up to [insert dollar 
amount] worth of goods or services 
each [insert time period] time you use 
the [card] [code] in our point-of-sale 
transfer service. 



(e) Fees (§ 205J(b)(5V i. 

(1) Per transfer charge . We will charge yrm 
[insert dollar amount J for each transfer you make 
using our [automated teller machines] [telephone 
bill-payment service] [point-of-sale transfer 
service]. 

(2) Fixed charge . We will charge you [insert 
dollar amount] each [insert time period] for our 
[automated teller machine service] [telephone 
bill-payment service] [point-of-sale transfer 
service]. 

(3) Average or minimum balance charge . We 
will only charge you for using our [automated 
teller machines] [telephone bill-payment service] 
[point-of-sale transfer service] if the [average] 
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[minimum] balance in your [checking account] 
[savings account] [accounts] falls below [insert 
dollar amount]. If it does, we will charge you 
[insert dollar amount] each [transfer] [insert time 
period]. 

(f) Confidentiality (j 205.1(b)(9)) . We will disclose 
information to third parties about your account or the 
transfers you make: 

(1) Where it is necessary for completing 
transfers, or 

(2) In order to verify the existence and 
condition of your account for a third party, such 
as a credit bureau or merchant, or 

(3) In order to comply with government agency 
or court orders, or 

(4) If you give us your written permission. 

(g) Documentation (§ 205.7(b>(6)V 

(1) Terminal transfers . You can get a receipt at 
the time you make any transfer to or from your 
account using one of our [automated teller 
machines] [or] [point-of-sale terminals]. 

(2) Preauthorized credits . If you have arranged 
to have direct deposits made to your account at 
least once every 60 days from the same person 
or company, (we will let you know if the deposit 
is [not] made.) [the person or company making 
the deposit will tell you every time they send us 
the money] [you can call us at (insert telephone 
number) to find out whether or not the deposit 
has been made]. 

(3) Periodic statements . You will get a 
[monthly] [quarterly] account statement (unless 
there are no transfers in a particular month. In 
any case you will get the statement at least 
quarterly). 

(4) Passbook account where the only possible 
electronic fund transfers are preauthorized 
credits . If you bring your passbook to us, we 
will record any electronic deposits that were 
made to your account since the last time you 
brought in your passbook. 



(h) Preauthorized payments ($205. ?(b¥6V (7) and (8): 
$205.10MV} . 

HV Right to stop payment and procedure for 
doing so . If you have told us in advance to make 
regular payments out of your account, you can 
stop any of these payments. Here's how: 

Call us at [insert telephone number], or write us 
at [insert address], in time for us to receive your 
request 3 business days or more before the 
payment is scheduled to be made. If you call, 
we may also require you to put your request in 
writing and get it to us within 14 days after you 
call. (We will charge you [insert amount] for 
each stop-payment order you give.) 

(2) Notice of varying amounts . If these regular 
payments may vary in amount, [we] [the person 
you are going to pay] will tell you, 10 days 
before each payment, when it will be made and 
how much it will be. (You may choose instead 
to get this notice only when the payment would 
differ by more than a certain amount from the 
previous payment, or when the amount would 
fall outside certain limits that you set.) 

Y3^ Liability for failure to stop payment of 
preauthorized transfer . If you order us to stop 
one of these payments 3 business days or more 
before the transfer is scheduled, and we do not 
do so, we will be liable for your losses or 
damages. 

(i) Financial institution's liability (S 205.7fb)(8)) . 

If we do not complete a transfer to or from your 
account on time or in the correct amount 
according to our agreement with you, we will be 
liable for your losses or damages. However, 
there are some exceptions. We will not be 
liable, for instance: 

(1) If, through no fault of ours, you do not have 
enough money in your account to make the 
transfer. 

(2) If the transfer would go over the credit limit 
on your overdraft line. 

(3) If the automated teller machine where you 
are making the transfer does not have enough 
cash. 

(4) If the [terminal] [system] was not working 
properly and you knew about the breakdown 
when you started the transfer. 
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(5) If circumstances beyond our control (such as 
fire or flood) prevent the transfer, despite 
reasonable precautions that we have taken. 



(6) There may be other exceptions stated 
agreement with you. 



in our 




m ATM fees (§205.7(b¥im When you use an ATM 
network not owned by us, you may be charged a fee by 
the ATM operator [or any network used] (and you may be 
charged a fee for a balance inquiry even if you do not 
complete a fund transfer). 

A-3--MODEL FORMS FOR ERROR RESOLUTION 
NOTICE 

(a) Initial and annual error resolution notice (§§ 
205.7(b¥lQ) and 205.80^ . 

In Case of Errors or Questions About Your 

Electronic Transfers 
Telephone us at [insert telephone number] 

Write us at [insert address] 
:.':'[oi- 
E-mail us at [insert electronic mail address]] 

as soon as you can, if you think your statement or receipt 
is wrong or if you need more information about a transfer 
listed on the statement or receipt. We must hear from you 
no later than 60 days after we sent the FIRST statement on 
which the problem or error appeared. 

(1) Tell us your name and account number (if 

(2) Describe the error or the transfer you are 
unsure about, and explain as clearly as you can 
why you believe it is an error or why you need 
more information. 

(3) Tell us the dollar amount of the suspected 
error. . 

If you tell us orally, we may require that you send us your 
complaint or question in writing within 10 business days. 

We will determine whether an error occurred within 10 
business days after we hear from you and will correct any 
error promptly. If we need more time, however, we may 
take up to 45 days to investigate your complaint or 
question. If we decide to do this, we will credit your 
account within 1 business days for the amount you think 
is in error, so that you will have the use of the money 
during the time it takes us to complete our investigation. 
If we ask you to put your complaint or question in writing 



and we do not receive it within 1 business days, we may 
not credit your account. 

For errors involving new accounts, point-of-sale, or 
foreign-initiated transactions, we may take up to 90 days 
to investigate your complaint or question. For new 
accounts, we may take up to 20 business days to credit 
your account for the amount you think is in error. 

We will tell you the results within three business days 
after completing our investigation. If we decide that there 
was no error, we will send you a written explanation. You 
may ask for copies of the documents that we used in our 
investigation. 

(b) Error resolution notice on periodic statements f§ 
205.8(b) ). 

In Case of Errors or Questions About Your 

Electronic Transfers 

Telephone us at [insert telephone number] 

or 

Write us at [insert address] 

as soon as you can, if you think your statement or receipt 
is wrong or if you need more information about a transfer 
on the statement or receipt. We must hear from you no 
later than 60 days after we sent you the FIRST statement 
on which the error or problem appeared. 

( 1) Tell us your name and account number (if 
any). 

(2) Describe the error or the transfer you are 
unsure about, and explain as clearly as you can 
why you believe it is an error or why you need 
more information. 

(3) Tell us the dollar amount of the suspected 
error. 

We will investigate your complaint and will correct any 
error promptly. If we take more than 1 business days to 
do this, we will credit your account for the amount you 
think is in error, so that you will have the use of the 
money during the time it takes us to complete our 
investigation. 



A-4--MODEL FORM FOR SERVICE-PROVIDING 
INSTITUTIONS 

§ 205.14(b)(l)(ii) 

ALL QUESTIONS ABOUT TRANSACTIONS MADE 
WITH YOUR (NAME OF CARD) CARD MUST BE 
DIRECTED TO US (NAME OF SERVICE PROVIDER), 
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AND NOT TO THE BANK OR OTHER FINANCIAL 
INSTITUTION WHERE YOU HAVE YOUR 
ACCOUNT. We are responsible for the [name of service] 
service and for resolving any errors in transactions made 
with your [name of card] card. 

We will not send you a periodic statement listing 
transactions that you make using your [name of card] 
card. The transactions will appear only on the statement 
issued by your bank or other financial institution. SAVE 
THE RECEIPTS YOU ARE GIVEN WHEN YOU USE 
YOUR [NAME OF CARD] CARD, AND CHECK 
THEM AGAINST THE ACCOUNT STATEMENT YOU 
RECEIVE FROM YOUR BANK OR OTHER 
FINANCIAL INSTITUTION. If you have any questions 
about one of these transactions, call or write us at 
[telephone number and address] [the telephone number 
and address indicated below]. 

IF YOUR [NAME OF CARD] CARD IS LOST OR 
STOLEN, NOTIFY US AT ONCE by calling or writing 
to us at [telephone number and address]. 

A-5--MODEL FORMS FOR GOVERNMENT 

AGENCIES (§ 205.15(d)(1) and (2)) 

(a) Disclosure bv government agencies of information 
about obtaining account balances and account histories (§ 
205.15rdVn(iYand(ii)) . 

You may obtain information about the amount of benefits 
you have remaining by calling [telephone number]. That 
information is also available [on the receipt you get when 
you make a transfer with your card at (an ATM)(a POS 
terminal)] [when you make a balance inquiry at an 
ATM] [when you make a balance inquiry at specified 
locations]. 

You also have the right to receive a written summary of 
transactions for the 60 days preceding your request by 
calling [telephone number]. [Optional: Or you may 
request the summary by contacting your caseworker.] 

(b) Disclosure of error resolution procedures for 
government agencies that do not provide periodic 
statements (§ 205.15fd)(l)(iii) and (d)(2)). 

In Case of Errors or Questions About Your 

Electronic Transfers 

Telephone us at [telephone number] 

Write us at [insert address] 

[or 

E-mail us at [insert electronic mail address]] 

as soon as you can, if you think an error has occurred in 
your [EBT] [agency's name for program] account. We 



must hear from you no later than 60 days after you learn 
of the error. You will need to tell us: 

• Your name and [case] [file] number. 

• Why you believe there is an error, and the dollar 
amount involved. 

• Approximately when the error took place. 

If you tell us orally, we may require that you send us your 
complaint or question in writing within 1 business days. 

We will determine whether an error occurred within 10 
business days after we hear from you and will correct any 
error promptly. If we need more time, however, we may 
take up to 45 days to investigate your complaint or 
question. If we decide to do this, we will credit your 
account within 1 business days for the amount you think 
is in error, so that you will have the use of the money 
during the time it takes us to complete our investigation. 
If we ask you to put your complaint or question in writing 
and we do not receive it within lObusiness days, wemay 
not credit your account. 

For errors involving new accounts, point-of-sale, or 
foreign-initiated transactions, we may take up to 90 days 
to investigate your complaint or question. For new 
accounts, we may take up to 20 business days to credit 
your account for the amount you think is in error. 

We will tell you the results within three business days 
after completing our investigation. If we decide that there 
was no error, we will send you a written explanation. You 
may ask for copies of the documents that we used in our 
investigation. 

If you need more information about our error resolution 
procedures, call us at [telephone number] [the telephone 
number shown above]. 

APPENDIX B TO PART 205-Federal Enforcement 
Agencies 

The following list indicates which Federal agency 
enforces Regulation E for particular classes of institutions. 
Any questions concerning compliance by a particular 
institution should be directed to the appropriate enforcing 
agency. Terms that are not defined in the Federal Deposit 
Insurance Act(12U.S.C.1813(s)) shall have the meaning 
given to them in the International Banking Act of 1 97 8 
(12U.S.C.3101). 

National banks/and Federal branches and Federal 
agencies of foreign banks 

District office of the Office of the Comptroller of 
the Currency where me institution is located. 
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State member banks, branches and aeencies of foreign 
banks (other than Federal branches. Federal agencies, and 
insured state branches of foreign banks), commercial 
lending companies owned or controlled bv foreign banks, 
and organizations operating under section 25 or 25(a) of 
the Federal Reserve Act 




Federal Reserve Bank serving the District in 
which the institution is located. 

Nonmember insured banks and insured state branches of 
foreign banks 

Federal Deposit Insurance Corporation regional 
director for the region in which the institution is 
located. 

Savings institutions insured under the Savings Association 
Insurance Fund of the FDIC and federally-chartered 
savings banks insured under the Bank Insurance Fund of 
the FDIC (but not including state-chartered savings banks 
insured under the Bank Insurance Fund) 

Office of Thrift Supervision Regional Director 
for the region in which the institution is located. 

Federal Credit Unions 

Division of Consumer Affairs, National Credit 
Union Administration, 1 775 Duke Street, 
Alexandria, Virginia 22314-3428 

Air Carriers 

Assistant General Counsel for Aviation 
Enforcement and Proceedings, Department of 
Transportation, 400 Seventh Street, S.W., 
Washington, D.C. 20590. 

Brokers and Dealers 



APPENDIX C TO PART 205-Issuance of Staff 
Interpretations 

Official Staff Interpretations 

Pursuant to section 915(d) of the act, the Board has 
designated the director and other officials of the Division 
of Consumer and Community Affairs as officials "duly 
authorized" to issue, at their discretion, official staff 
interpretations of this regulation. Except in unusual 
circumstances, such interpretations will not be issued 
separately but will be incorporated in an official 
commentary to the regulation, which will be amended 
periodically. 



Requests for Issuance of Official Staff Interpretations 

A request for an official staff interpretation shall be in 
writing and addressed to the Director, Division of 
Consumer and Community Affairs, Board of Governors 
of the Federal Reserve System, Washington, D.C. 2055 1 . 
The request shall contain a complete statement of all 
relevant facts concerning the issue, including copies of all 
pertinent documents. 

Scope of Interpretations 

No staff interpretations will be issued approving financial 
institutions' forms or statements. This restriction does not 
apply to forms or statements whose use is required or 
sanctioned by a government agency. 

By order of the Board of Governors of the Federal 
Reserve System, April 19, 1996. 

William W. Wiles, 
Secretary of the Board. 

[FR Doc. 96-00000 Filed 00-00-96; 8 : 45 am] 
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Division of Market Regulation, Securities and 
Exchange Commission, Washington, D.C. 
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Retailers, Consumer Finance Companies-Certain Other 
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Federal Trade Commission, Electronic Fund 
Transfers, Washington, D.C. 20580. 
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SUPPLEMENT I TO PART 205-OFFICIAL STAFF 
INTERPRETATIONS 

SECTION 205.2 ~ Definitions 

2(a) Access device . 

*• Examples . The term access device includes debit 
cards, personal identification numbers (PINs), telephone 
transfer and telephone bill payment codes, and other 
means that may be used by a consumer to initiate an 
electronic fund transfer (EFT) to or from a consumer 
account. The term does not include magnetic tape or 
other devices used internally by a financial institution to 
initiate electronic transfers. 

2 . Checks used to capture information . The term "access 
device" does not include a check or draft used to capture 
the MICR (Magnetic Ink Character Recognition) 
encoding to initiate a one-time ACH debit. For example, 
if a consumer authorizes a one-time ACH debit from the 
consumer's account using a blank, partially completed, or 
fully completed and signed check for the merchant to 
capture the routing, account, and serial numbers to initiate 
the debit, the check is not an access device. (Although the 
check is not an access device under Regulation E, the 
transaction is nonetheless covered by the regulation. See 
comment 3(b)- l(v).) 

2(b) Account. 

1. Consumer asset account . The term consumer asset 
account includes: 

i. Club accounts; such as vacation clubs. 

In many cases, however, these accounts 
are exempt from the regulation under § 
205.3(c)(5) because all electronic 
transfers to or from the account have 
been preauthorized by the consumer 
and involve another account of the 
consumer at the same institution. 

ii. A retail repurchase agreement (repo), 

which is a loan made to a financial 
institution by a consumer that is 
collateralized by government or 
government-insured securities. 

2. Examples of accounts not covered by Regulation E 
include: 

i. Profit-sharing and pension accounts 

established under a trust agreement, 
which are exempt under § 205.2(b)(2). 



ii. Escrow accounts, such as those 

established to ensure payment of items 
such as real estate taxes, insurance 
premiums, or completion of repairs or 
improvements. 

iii. Accounts for accumulating funds to 

purchase U.S. savings bonds. 

Paragraph 2(b)(2) 

1. Bona fide trust agreements . The term bona fi He trust 
agreement is not defined by the act or regulation; 
therefore, financial institutions must look to state or other 
applicable law for interpretation. 

2. Custodial agreements . An account held under a 
custodial agreement that qualifies as a trust under the 
Internal Revenue Code, such as an individual retirement 
account, is considered to be held under a trust agreement 
for purposes of Regulation E. 

2(d) Business day . 

1 • Duration . A business day includes the entire 24-hour 
period ending at midnight, and a notice required by the 
regulation is effective even if given outside normal 
business hours. The regulation does not require, however, 
that a financial institution make telephone lines available 
on a 24-hour basis. 

2. Substantially all business functions . "Substantially all 
business functions" include both the public and the 
back-office operations of the institution. For example, if 
the offices of an institution are open on Saturdays for 
handling some consumer transactions (such as deposits, 
withdrawals, and other teller transactions), but not for 
performing internal functions (such as investigating 
account errors), then Saturday is not a business day for 
that institution; In this case, Saturday does not count 
toward the business-day standard set by the regulation for 
reporting lost or stolen access devices, resolving errors, 
■ e tc.'.- 

3.. Short hours . A financial institution may determine >t 
its election, whether an abbreviated day is a business day. 
For example, if an institution engages in substantially all 
business functions until noon on Saturdays instead of its 
usual 3 :00 p.m. closing, it may consider Saturday a 
business day. 

4. Telephone line . If a financial institution makes a 
telephone line available on Sundays for reporting the loss 
or theft of an access device, but performs no other 
business functions, Sunday is not a business day under the 
"substantially all business functions" standard. 
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2 HiY Electronic terminal . 

1 , Point-of-sale (POS) payments initiated bv telephone . 
Because the term electronic terminal excludes a telephone 
operated by a consumer, a financial institution need not 
provide a terminal receipt when: 

i. A consumer uses a debit card at a 

public telephone to pay for the call. 

ii. A consumer initiates a transfer by a 

means analogous in function to a 
telephone, such as by home banking 
equipment or a facsimile machine. 

2 POS terminals . A POS terminal that captures data 
electronically, for debiting or crediting to a consumer's 
asset account, is an electronic terminal for purposes of 
Regulation E even if no access device is used to initiate 
the transaction. (See § 205.9 for receipt requirements.) 

3. Teller-operated terminals . A terminal or other 
computer equipment operated by an employee of a 
financial institution is not an electronic terminal for 
purposes of the regulation. However, transfers initiated at 
such terminals by means of a consumer's access device 
(using the consumers PIN, for example) are EFTsandare 
subject to other requirements of the regulation. If an 
access device is used only for identification purposes or 
for determining the account balance, the transfers are not 
EFTs for purposes of the regulation. 

2(10 Preauthorized electronic fund transfer . 

1 . Advance authorization . A "preauthorized electronic 
fund transfer" under Regulation E is one authorized by the 
consumer in advance of a transfer that will take place on 
a recurring basis, at substantially regular intervals, and 
will require no further action by the consumer to initiate 
the transfer. In a bill-payment system, for example, if the 
consumer authorizes a financial institution to make 
monthly payments to a payee by means of EFTs, and the 
payments take place without further action by the 
consumer, the payments are preauthorized EFTs. In 
contrast, if the consumer must take action each month to 
initiate a payment (such as by entering instructions on a 
touch-tone telephone or home computer), the payments 
are not preauthorized EFTs. 

2(m) Unauthorized electronic fund transfer . 

1 . Transfer bv institution's employee . A consumer has no 
liability for erroneous or fraudulent transfers initiated by 
an employee of a financial institution. 



2. Authority . If a consumer furnishes an access device 
and grants authority to make transfers to a person (such as 
a family member or co-worker) who exceeds the authority 
given, the consumer is fully liable for the transfers unless 
the consumer has notified the financial institution that 
transfers by that person are no longer authorized. 

3. Access device obtained through robbery or fraud . An 
unauthorized EFT includes a transfer initiated by a person 
who obtained the access device from the consumer 
through fraud or robbery. 

4. Forced initiation . An EFT at an automated teller 
machine (ATM) is an unauthorized transfer if the 
consumer has been induced by force to initiate the 
transfer. 

5. Reversal of direct deposits . The reversal of a direct 
deposit made in error is not an unauthorized EFT when it 
involves: 

I A credit made to the wrong consumer's 

account; 

ii. A duplicate credit made to a 

consumer's account; or 

iii. A credit in the wrong amount (for 

example, when the amount credited to 
the consumer's account differs from the 
amount in the transmittal instructions). 

SECTION 205.3 - Coverage 

3(a) General 

1. Accounts covered . The requirements of the regulation 
apply only to an account for which an agreement for EFT 
services to or from the account has been entered into 
between: 

i. The consumer and the financial 

institution (including an account for 
which an access device has been issued 
to the consumer, for example); 

ii. The consumer and a third party (for 

preauthorized debits or credits, for 
example), when the account-holding 
institution has received notice of the 
agreement and the fund transfers have 
begun. 

2. Automated clearing house (ACH) membership . The 
fact that membership in an ACH requires a financial 
institution to accept EFTs to accounts at the institution 
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does not make every account of that institution subject to 
the regulation. 

3. Foreign applicability . Regulation E applies to all 
persons (including branches and other offices of foreign 
banks located in the United States) that offer EFT services 
to residents of any state, including resident aliens. It 
covers any account located in the United States through 
which EFTs are offered to a resident of a state. This is the 
case whether or not a particular transfer takes place in the 
United States and whether or not the financial institution 
is chartered in the United States or a foreign country. The 
regulation does not apply to a foreign branch of a U. S . 
bank unless the EFT services are offered in connection 
with an account in a state as defined in § 205.2(1). 



3(b) Electronic fund transfer . 



1 . Fund transfers covered , 
transfer includes: 



The term electronic fund 



A deposit made at an ATM or other 
electronic terminal (including a deposit 
in cash or by check) provided a specific 
agreement exists between the financial 
institution and the consumer for EFTs 
to or from the account to which the 
deposit is made. 



enable the merchant or other payee to 
capture the routing, account, and serial 
numbers to initiate the transfer, whether 
the check is blank, partially completed, 
or fully completed and signed; whether 
the check is presented at POS or is 
mailed to a merchant or other payee or 
lockbox and later converted to an EFT; 
or whether the check is retained by the 
consumer, the merchant, or other 
payee, or the payee's financial 
institution. 

vi. A payment made by a bill payer under 

a bill-payment service available to a 
consumer via a computer or other 
electronic means, unless the terms of 
the bill-payment service explicitly state 
that all payments, or all payments to a 
particular payee or payees, will be 
solely by check, draft, or similar paper 
instrument drawn on the consumer's 
account, and the payee or payees that 
will be paid in this manner are 
identified to the consumer. 

2. Fund transfers not covered . The term electronic fund 
transfer does not include: 



ii. A transfer sent via ACH. For example, 

social security benefits under the U.S. 
Treasury's direct-deposit program are 
covered, even if the listing of payees 
and payment amounts reaches the 
account-holding institution by means of 
a computer printout from a 
correspondent bank. 

iii. A preauthorized transfer credited or 

debited to an account in accordance 
with instructions contained on magnetic 
tape, even if the financial institution 
holding the account sends or receives a 
composite check. 

iv. A transfer from the consumer's account 

resulting from a debit-card transaction 
at a merchant location, even if no 
electronic terminal is involved at the 
time of the transaction, if the 
consumer's asset account is 
subsequently debited for the amount of 
the transfer. 

v. A transfer via ACH where the 

consumer has provided a check to 



i. A payment that does not debit or credit 

a consumer asset account, such as a 
payroll allotment to a creditor to repay 
a credit extension (which is deducted 
fromsalary). 

ii. A payment made in currency by a 

consumer to another person at an 
electronic terminal. 

iii. A preauthorized check drawn by the 

financial institution on the consumer's 
account (such as an interest or other 
recurring payment to the consumer or 
another party), even if the check is 
computer-generated. 



3 . Authorization of one-time EFT initiated using MICR 
encoding on a check . A consumer authorizes a one-time 
EFT (in providing a check to a merchant or other payee 
for the MICR encoding), where the consumer receives 
notice that the transaction will be processed as an EFT 
and completes the transaction. Examples of notice 
include, but are not limited to, signage at POS and written 
statements. 



REG E INTERPRETA TION 4 



2005; ACH RULES. 



REGULA TION E STAFF INTERPRETA TION 



3(c\ Exclusions from coverage . 
Paragraph 3(c)(1) - Checks. 

1 . Re-presented checks . The electronic re-presentment of 
a returned check is not covered by Regulation E because 
the transaction originated by check. Regulation E does 
apply, however, to any fee authorized by the consumer to 
be debited electronically from the consumer's account 
because the check was returned for insufficient funds. 
Authorization occurs where the consumer has received 
notice that a fee imposed for returned checks will be 
debited electronically from the consumer ' s account. 

2. Check used to capture information for a one-time EFT . 
See comment 3(b)-l(v). 



Paragraph 3(c)(2) 
authorization. 



Check guarantee or 



1 . Memo posting . Under a check guarantee or check 
authorization service, debiting of the consumer's account 
occurs when the check or draft is presented for payment. 
These services are exempt from coverage, even when a 
temporary hold on the account is memo-posted 
electronically at the time of authorization. 

Paragraph 3(c)(3) - Wire or other similar transfers. 

1 . Fedwire and ACH . If a financial institution makes a 
fund transfer to a consumer's account after receiving funds 
through Fedwire or a similar network, the transfer by 
ACH is covered by the regulation even though the 
Fedwire or network transfer is exempt. 

2. Article 4A . Financial institutions that offer telephone- 
initiated Fedwire payments are subj ect to the requirements 
of UCC § 4A-202, which encourages verification of 
Fedwire payment orders pursuant to a security procedure 
established by agreement between the consumer and the 
receiving bank. These transfers are not subject to 
Regulation E and the agreement is not considered a 
telephone plan if the service is offered separately froma 
telephone bill-payment or other prearranged plan subject 
to Regulation E. The Board's Regulation J specifies the 
rules applicable to funds handled by Federal Reserve 
Banks. To ensure that the rules for all fund transfers 
through Fedwire are consistent, the Board used its 
preemptive authority under UCC § 4A- 107 to determine 
that subpart B of Regulation J, including the provisions of 
Article 4A, applies to all fund transfers through Fedwire, 
even if a portion of the fund transfer is governed by the 
EFTA. The portion of the fund transfer that is governed 
by the EFTA is not governed by subpart B. 



3. Similar fund transfer systems . Fund transfer systems 
that are similar to Fedwire include the Clearing House 
Interbank Payments System (CHIPS), Society for 
Worldwide Interbank Financial Telecommunication 
(SWIFT), Telex, and transfersmade on the books of 
correspondent banks. 



Paragraph 3(c)(4) 
transfers. 



Securities and commodities 



1. Coverage . The securities exemption applies to 
securities and commodities that may be sold by a 
registered broker-dealer or futures commission merchant, 
even when the security or commodity itself is not 
regulated by the Securities and Exchange Commission or 
the Commodity Futures Trading Commission. 

2 Exam ple of exempt transfer . The exemption applies to 
a transfer involving a transfer initiated by a telephone 
order to a stockbroker to buy or sell securities or to 
exercise a margin call. 



3. Examples of nonexempt transfers . The exemption 
does not apply to a transfer involving: 

i. A debit card or other access device that 

accesses a securities or commodities 
account such as a money market mutual 
fund and that the consumer uses for 
purchasing goods or services or for 
obtaining cash. 

h\ A payment of interest or dividends into 

the consumer's account (for example, 
from a brokerage firm or from a 
Federal Reserve Bank for government 
securities). 

Paragraph 3(c)(5) -- Automatic transfers by account- 
holding institution. 

1 . Automatic transfers exempted . The exemption applies 
to::'; ".>■'.■'/.-.■ 



Electronic debits or credits to consumer 
accounts for check charges, stop- 
payment charges, NSF charges, 
overdraft charges, provisional credits, 
error adjustments, and similar items 
that are initiated automatically on the 
occurrence of certain events. 




Debits to consumer accounts for group 
insurance available only through the 
financial institution and payable only 
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by means of an aggregate payment 
from me institution to the insurer, 

iii. EFTs between a thrift institution and its 

paired commercial bank in the state of 
Rhode Island, which are deemed under 
state law to be intra-institutional 

iv. Automatic transfers between a 

consumer's accounts within the same 
financial institution, even if the account 
holders on the two accounts are not 
identical. 

2. Automatic transfers not exempted . Transfers between 
accounts of the consumer at affiliated institutions (such as 
between a bank and its subsidiary or within a holding 
company) are not intra-institutional transfers, and thus do 
not qualify for the exemption. 

Paragraph 3(c)(6) -- Telephone-initiated transfers. 

1. Written plan or agreement . A transfer that the 
consumer initiates by telephone is covered by Regulation 
E if the transfer is made under a written plan or agreement 
between the consumer and the financial institution making 
the transfer. A written statement available to the public or 
to account holders that describes a service allowing a 
consumer to initiate transfers by telephone constitutes a 
plan- for example, a brochure, or material included with 
periodic statements. The following, however, do not by 
themselves constitute a written plan or agreement: 

i. A hold-harmless agreement on a 

signature card that protects the 
institution if the consumer requests a 
transfer. 

ii. A legend on a signature card, periodic 

statement, or passbook that limits the 
number of telephone-initiated transfers 
the consumer can make from a savings 
account because of reserve 
requirements under Regulation D (12 
CFRpart204). 

iii. An agreement permitting the consumer 

to approve by telephone the rollover of 
funds at the maturity of an instrument. 

2. Examples of covered transfers . When a written plan or 
agreement has been entered into, a transfer initiated by a 
telephone call from a consumer is covered even though: 

i. An employee of the financial institution 

completes the transfer manually (for 



example, by means of a debit memo or 
deposit slip). 

The consumer is required to make a 
separate request for each transfer. 



in. 



iv. 



v. 



The consumer uses the plan 
infrequently. 



The consumer initiates the transfer via 
a facsimile machine. 

The consumer initiates the transfer 
using a financial institution's audio- 
response or voice-response telephone 
system. 



Paragraph 3(c)(7) - Small institutions. 

1 * Coverage . This exemption is limited to preauthorized 
transfers ; institutions that offer other EFTs must comply 
with the applicable sections of the regulation as to such 
services. The preauthorized transfers remain subject to §§ 
913, 915, and 916 of the act and § 205.10(e), and are 
therefore exempt from UCC Article 4A. 

SECTION 205.4 -- General Disclosure Requirements; 
Jointly Offered Services 

4(a) Form of disclosures . 

1 * General . Although no particular rules govern type 
size, number of pages, or the relative conspicuousness of 
various terms, the disclosures must be in a clear and 
readily understandable written form that the consumer 
may retain. Numbers or codes are considered readily 
understandable if explained elsewhere on the disclosure 
form. 

2. Foreign language disclosures . Disclosures may be 
made in languages other than English, provided they are 
available in English upon request. 

SECTION 205.5 — Issuance of Access Devices 

1- Coverage . The provisions of this section limit the 
circumstances under which a financial institution may 
issue an access device to a consumer. Making an 
additional account accessible through an existing access 
device is equivalent to issuing an access device and is 
subject to the limitations of this section. 
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5(aY Solicited issuance . 
Paragraph 5(a)(1) 

1. Joint account . For a joint account, a financial 
institution may issue an access device to each account 
holder if the requesting holder specifically authorizes the 
issuance. 

2. Permissible forms of request . The request for an 
access device may be written or oral (for example, in 
response to a telephone solicitation by a card issuer). 

Paragraph (a)(2) 

1 . One-for-one rule . In issuing a renewal or substitute 
access device, a financial institution may not provide 
additional devices. For example, only one new card and 
PIN may replace a card and PIN previously issued. If the 
replacement device permits either additional or fewer 
types of electronic fund transfer services, a change-in- 
terms notice or new disclosures are required. 

2. Renewal or substitution by a successor institution . A 
successor institution is an entity that replaces the original 
financial institution (for example, following a corporate 
merger or acquisition) or that acquires accounts or 
assumes the operation of an EFT system. 

5(b) Unsolicited issuance . 

1 • Compliance . A financial institution may issue an 
unsolicited access device (such as the combination of a 
debit card and PIN) if the institution's ATM system has 
been programmed not to accept the access device until 
after the consumer requests and the institution validates 
the device. Merely instructing a consumer not to use an 
unsolicited debit card and PIN until after the institution 
verifies the consumer's identity does not comply with the 
regulation. 

2. PINS . A financial institution may impose no liability 
on a consumer for unauthorized transfers involving an 
unsolicited access device until the device becomes an 
"accepted access device" under the regulation. A card 
and PIN combination may be treated as an accepted 
access device once the consumer has used it to make a 
transfer. 

3. Functions of PIN . If an institution issues a PIN at the 
consumer's request, the issuance may constitute both a 
way of validating the debit card and the means to identify 
the consumer (required as a condition of imposing 
liability for unauthorized transfers). 



4. Verification of identity . To verify the consumer's 
identity, a financial institution may use any reasonable 
means, such as a photograph, fingerprint, personal visit, 
signature comparison, or personal information about the 
consumer. However, even if reasonable means were used, 
if an institution fails to verify correctly the consumer's 
identity and an imposter succeeds in having the device 
validated, the consumer is not liable for any unauthorized 
transfers from the account. 

SECTION 205.6 » Liability of Consumer For 
Unauthorized Transfers 

6fa^ Conditions for liability . 

1 . Means of identification . A financial institution may 
use various means for identifying the consumer to whom 
the access device is issued, including but not limited to: 

i. Electronic or mechanical confirmation 

(such as a PIN). 

ii. Comparison of the consumer's 

signature, fingerprint, or photograph. 

2. Multiple users . When more than one access device is 
issued for an account, the financial institution may, but 
need not, provide a separate means to identify each user 
of the account. 

6(b) Limitations on amount of liability . 

1 . Application of liability provisions . There are three 
possible tiers of consumer liability for unauthorized EFTs 
depending on the situation. A consumer may be liable for 
(I) I up to $50; (2) up to $500; or (3) an unlimited amount 
depending on when the unauthorized EFT occurs. More 
than one tier may apply to a given situation because each 
corresponds to a different (sometimes overlapping) time 
period or set of conditions. 

2. Consumer negligence . Negligence by the consumer 
cannot be used as the basis for imposing greater liability 
than is permissible under Regulation E. Thus, consumer 
behavior that may constitute negligence under state law, 
such as writing the PIN on a debit card or on a piece of 
paper kept with the card, does not affect the consumer's 
liability for unauthorized transfers. (However, refer to 
comment 2(m)-2 regarding termination of the authority of 
given by the consumer to another person.) 

3. Limits on liability . The extent of the consumer's 
liability is determined solely by the consumer's 
promptness in reporting the loss or theft of an access 
device. Similarly, no agreement between the consumer 
and an institution may impose greater liability on the 
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consumer for an unauthorized transfer than the limits 
provided in Regulation E. 




Paragraph 6(b)(1) ~ Timely notice given. 

* $50 limit applies . The basic liability limit is $50. For 
example, the consumer's card is lost or stolen on Monday 
and the consumer learns of the loss or theft on 
Wednesday. If the consumer notifies the financial 
institution within two business days of learning of the loss 
or theft (by midnight Friday), the consumer's liability is 
limited to $50 or the amount of the unauthorized transfers 
that occurred before notification, whichever is less. 

2. Knowledge of loss or theft of access device . The fact 
that a consumer has received a periodic statement that 
reflects unauthorized transfers may be a factor in 
determining whether the consumer had knowledge of the 
loss or theft, but cannot be deemed to represent conclusive 
evidence that the consumer had such knowledge. 

3. Two-business-day rule . The two-business-day period 
does not include the day the consumer learns of the loss or 
theft or any day that is not a business day. The rule is 
calculated based on two 24-hour periods, without regard 
to the financial institution's business hours or the time of 
day that the consumer learns of the loss or theft. For 
example, a consumer learns of the loss or theft at 6:00 
p.m. on Friday. Assuming that Saturday is a business day 
and Sunday is not, the two-business-day period begins on 
Saturday and expires at 11:59 p.m. on Monday, not at the 
end of the financial institution's business day on Monday. 

Paragraph 6(b)(2) -- Timely notice not given 

1 . $500 limit applies . The second tier of liability is $500. 
For example, the consumer's card is stolen on Monday 
and the consumer learns of the theft that same day. The 
consumer reports the theft on Friday. The $500 limit 
applies because the consumer failed to notify the financial 
institution within two business days of learning of the theft 
(which would have been by midnight Wednesday). How 
much the consumer is actually liable for, however, 
depends on when the unauthorized transfers take place. 
In this example, assume a $ 1 00 unauthorized transfer was 
made on Tuesday and a $600 unauthorized transfer on 
Thursday. Because the consumer is liable for the amount 
of the loss that occurs within the first two business days 
(but no more than $50), plus the amount of the 
unauthorized transfers that occurs after the first two 
business days and before the consumer gives notice, the 
consumer's total liability is $500 ($50 of the $ 100 transfer 
plus $450 of the $600 transfer, in this example). But if 
$600 was taken on Tuesday and $100 on Thursday, the 
consumer's maximum liability would be $ 1 50 ($50 of the 
$600 plus $100). 



Paragraph 6(b)(3) — ' Periodic statement; timely notice 
not given. 

1 . Unlimited liability applies . The standard of unlimited 
liability applies if unauthorized transfers appear on a 
periodic statement, and may apply in conjunction with the 
first two tiers of liability. If a periodic statement shows an 
unauthorized transfer made with a lost or stolen debit 
card, the consumer must notify the financial institution 
within 60 calendar days after the periodic statement was 
sent; otherwise, the consumer faces unlimited liability for 
all unauthorized transfers made after the 60-day period. 
The consumer's liability for unauthorized transfers before 
the statement is sent, and up to 60 days following, is 
determined based on the first two tiers of liability: up to 
$50 if the consumer notifies the financial institution within 
two business days of learning of the loss or theft of the 
card and up to $500 if the consumer notifies the institution 
after two business days of learning of the loss or theft 

2. Transfers not involving access device . The first two 
tiers of liability do not apply to unauthorized transfers 
from a consumer's account made without an access device. 
If, however, the consumer fails to report such 
unauthorized transfers within 60 calendar days of the 
financial institution's transmittal of the periodic statement, 
the consumer may be liable for any transfers occurring 
after the close of the 60 days and before notice is given to 
the institution. For example, a consumer's account is 
electronically debited for $200 without the consumer's 
authorization and by means other than the consumer's 
access device. If the consumer notifies the institution 
within 60 days of the transmittal of the periodic statement 
that shows the unauthorized transfer, the consumer has no 
liability/However, if in addition to the $200, the 
consumer's account is debited for a $400 unauthorized 
transfer on the 61st day and the consumer fails to notify 
the institution of the first unauthorized transfer until the 
62nd day, the consumer may be liable for the full $400. 

Paragraph 6(b)(4) - Extension of time limits. 

1. Extenuating circumstances . Examples of 
circumstances that require extension of the notification 
periods under this section include the consumer's extended 
travel or hospitalization. 

Paragraph 6(b)(5) — Notice to financial institution. 

1 Receipt of notice . A financial institution is considered 
to have received notice for purposes of limiting the 
consumer's liability if notice is given in a reasonable 
manner, even if the consumer notifies the institution but 
uses an address or telephone number other than the one 
specified by the institution. 
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2. Notice bv third party . Notice to a financial institution 
by a person acting on the consumer's behalf is considered 
valid under this section. For example, if a consumer is 
hospitalized and unable to report the loss or theft of an 
access device, notice is considered given when someone 
acting on the consumer's behalf notifies the bank of the 
loss or theft. A financial institution may require 
appropriate documentation from the person representing 
the consumer to establish that the person is acting on the 
consumer's behalf 

3. Content of notice . Notice to a financial institution is 
considered given when a consumer takes reasonable steps 
to provide the institution with the pertinent account 
information. Even when the consumer is unable to 
provide the ac count number or the card number in 
reporting a lost or stolen access device or an unauthorized 
transfer, the notice effectively limits the consumer's 
liability if the consumer otherwise identifies sufficiently 
the account in question. For example, the consumer may 
identify the account by the name on the account and the 
type of account in question. 

SECTION 205.7 « Initial Disclosures 

1(2l\ Timing of disclosures . 

1 . Early disclosures . Disclosures given by a financial 
institution earlier than the regulation requires (for 
example, when me consumer opens a checking account) 
need not be repeated when the consumer later enters into 
an agreement with a third party who will initiate 
preauthorized transfers to or from the consumer's account, 
unless the terms and conditions differ from those that the 
institution previously disclosed. On the other hand, if an 
agreement is directly between the consumer and the 
account-holding institution, disclosures must be given in 
close proximity to the event requiring disclosure, for 
example, when the consumer contracts for a new service. 

2. Lack of advance notice of a transfer . Where a 
consumer authorizes a third party to debit or credit the 
consumer's account, an account-holding institution that 
has not received advance notice of the transfer or transfers 
must provide the required disclosures as soon as 
reasonably possible after the first debit or credit is made, 
unless the institution has previously given disclosures. 

3. Addition of new accounts . If a consumer opens a new 
account permitting EFTs at a financial institution, and the 
consumer already has received Regulation E disclosures 
for another account at that institution, the institution need 
only disclose terms and conditions that differ from those 
previously given. 



4. Addition of EFT services . If an EFT service is added 
to a consumer's account and is subject to terms and 
conditions different from those described in the initial 
disclosures, disclosures for the new service are required. 
The disclosures must be provided when the consumer 
contracts for the new service or before the first EFT is 
made using the new service. 

5. Addition of service in interchange systems . If a 
financial institution joins an interchange or shared 
network system (which provides access to terminals 
operated by other institutions), disclosures are required 
for additional EFT services not previously available to 
consumers if the terms and conditions differ from those 
previously disclosed. 

6. Disclosures covering all EFT services offered . An 
institution may provide disclosures covering all EFT 
services that it offers, even if some consumers have not 
arranged to use all services. 

7(hV Content of disclosures . 

Paragraph 7(b)(1) - Liability of consumer. 

1. No liability imposed bv financial institution . If a 
financial institution chooses to impose zero liability for 
unauthorized EFTs, it need not provide the liability 
disclosures. If the institution later decides to impose 
liability, however, it must first provide the disclosures. 

2. Preauthorized transfers . If the only EFTs from an 
account are preauthorized transfers, liability could arise 
if the consumer fails to report unauthorized transfers 
reflected on a periodic statement. To impose such 
liability on the consumer, the institution must have 
disclosed the potential liability and the telephone number 
and address for reporting unauthorized transfers. 

3. Additional information . At the institution's option, the 
summary of the consumer's liability may include advice 
on promptly reporting unauthorized transfers or the loss 
or theft of the access device. 

Paragraph 7(b)(2) » Telephone number and address. 

1. Disclosure of telephone numbers . An institution may 
use the same or different telephone numbers in the 
disclosures for the purpose of: 

i. Reporting the loss or theft of an access 

device or possible unauthorized 
transfers; 




Inquiring about the 
preauthorized credit; 



receipt of a 
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hi. Stopping payment of a preauthorized 

debit; 

iv. Giving notice of an error. 

2. Location of telephone number . The telephone number 
need not be incorporated into the text of the disclosure; 
for example, the institution may instead insert a reference 
to a telephone number that is readily available to the 
consumer, such as "Call your branch office. The number 
is shown on your periodic statement." However, an 
institution must provide a specific telephone number and 
address, on or with the disclosure statement, for reporting 
a lost or stolen access device or a possible unauthorized 
transfer. 

Paragraph 7(b)(4) - Types of transfers; limitations. 

1 . Security limitations . Information about limitations on 
the frequency and dollar amount of transfers generally 
must be disclosed in detail, even if related to security 
aspects of the system. If the confidentiality of certain 
details is essential to the security of an account or system, 
these details may be withheld (but the fact that limitations 
exist must still be disclosed). For example, an institution 
limits cash ATM withdrawals to $100 per day. The 
institution may disclose that daily withdrawal limitations 
apply and need not disclose that the limitations may not 
always be in force (such as during periods when its ATMs 
are off-line). 

2. Restrictions on certain deposit accounts . A limitation 
on account activity that restricts the consumer's ability to 
make EFTs must be disclosed even if the restriction also 
applies to transfers made by nonelectronic means. For 
example, Regulation D (12 CFR Part 204) restricts the 
number of payments to third parties that may be made 
from a money market deposit account; an institution that 
does not execute fund transfers in excess of those limits 
must disclose the restriction as a limitation on the 
frequency of EFTs. 

3. Preauthorized transfers . Financial institutions are not 
required to list preauthorized transfers among the types of 
transfers that a consumer can make. 

Paragraph 7(b)(5)- Fees. 

1 . Disclosure of EFT fees . An institution is required to 
disclose all fees for EFTs or the right to make them. 
Others fees (for example, minimum-balance fees, stop- 
payment fees, or account overdrafts) may, but need not, 
be disclosed (but see Regulation DD, 12 CFR Part 230. 
An institution is not required to disclose fees for inquiries 
made at an ATM since no transfer of funds is involved. 



2. Fees also applicable to non-EFT . A per-item fee for 
EFTs must be disclosed even if the same fee is imposed 
on nonelectronic transfers. If a per-item fee is imposed 
only under certain conditions, such as when the 
transactions in the cycle exceed a certain number, those 
conditions must be disclosed. Itemization of the various 
fees may be provided on the disclosure statement or on an 
accompanying document that is referenced in the 
statement. 

3. Interchange system fees . Fees paid by the account- 
holding institution to the operator of a shared or 
interchange ATM system need not be disclosed, unless 
they are imposed on the consumer by the account-holding 
institution. Fees for use of an ATM that are debited 
directly from the consumer's account by an institution 
other than the account-holding institution (for example, 
fees included in the transfer amount) need not be 
disclosed. (See § 205.7(b)( 1 1) for the general notice 
requirement regarding fees that may be imposed by ATM 
operators and by a network used to complete the transfer.) 

Paragraph 7(b)(9) - Confidentiality. 

1 . ■ Information provided to third parties . An institution 
must describe the circumstances under which any 
information relating to an account to or from which EFTs 
are permitted will be made available to third parties, not 
just information concerning those EFTs. The term "third 
parties" includes affiliates such as other subsidiaries of the 
same holding company. 

Paragraph 7(b)(10) — Error resolution. 

1 . Substantially similar . The error resolution notice must 
be substantially similar to the model form in appendix A. 
An institution may use different wording so long as the 
substance of the notice remains the same, may delete 
inapplicable provisions (for example, the requirement for 
written confirmation of an oral notification), and may 
substitute substantive state law requirements affording 
greater consumer protection than Regulation E. 

2. Extended time-period for certain transactions . To take 
advantage of the longer time periods for resolving errors 
under § 205 . 1 1 (c)(3) (for new accounts as defined in 
Regulation CC, transfers initiated outside the United 
States, or transfers resulting from POS debit-card 
transactions), a financial institution must have disclosed 
these longer time periods. Similarly, an institution that 
relies on the exception from provisional crediting in § 
205 .1 1 (c)(2) for accounts subject to Regulation T ( 1 2 
CF.R. Part 220) must have disclosed accordingly. 
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SECTION 205.8 - 
Resolution Notice 



Change-in-Terms Notice; Error 



8(a> €han%e-in-terms notice . 

1 . Form of notice . No specific form or wording is 
required for a change-in-terms notice/The notice may 
appear on a periodic statement, or may be given by 
sending a copy of a revised disclosure statement, provided 
attention is directed to the change (for example, in a cover 
letter referencing the changed term). 

2. Changes not requiring notice . The following changes 
do not require disclosure: 

i. Closing some of an institution's ATMs; 

ii. Cancellation of an access device. 

3 . Limitations on transfers . When the initial disclosures 
omit details about limitations because secrecy is essential 
to the security of the account or system, a subsequent 
increase in those limitations need not be disclosed if 
secrecy is still essential. If, however, an institution had no 
limits in place when the initial disclosures were given and 
now wishes to impose limits for the first time, it must 
disclose at least the fact that limits have been adopted. 
(See also § 205.7(b)(4) and the related commentary.) 

4. Change in telephone number or address . When a 
financial institution changes the telephone number or 
address used for reporting possible unauthorized transfers, 
a change-in-terms notice is required only if the institution 
will impose liability on the consumer for unauthorized 
transfers under § 205.6. (See also § 205.6(a) and the 
related commentary.) 

8fb^ Error resolution notice 

1 . Change between annual and periodic notice . If an 
institution switches from an annual to a periodic notice, or 
vice versa, me first notice under the new method must be 
sent no later than 12 months after the last notice sent 
under the old method. 

2. Exception for new accounts . For new accounts, 
disclosure of the longer error resolution time periods 
under § 205.1 1(c)(3) is not required in the annual error 
resolution notice that may be provided with each periodic 
statement as an alternative to the annual notice. 



SECTION 205.9--Receipts At Electronic Terminals; 
Periodic Statements 

9(a) Receipts at electronic terminals . 

1 Recei pts furnished onl y on request . The regulation 
requires that a receipt be "made available." A financial 
institution may program its electronic terminals to provide 
a receipt only to consumers who elect to receive one. 

2. Third party providing receipt . An account-holding 
institution may make terminal receipts available through 
third parties such as merchants or other financial 
institutions. 

V Inclusion of promotional material . A financial 
institution may include promotional material on receipts 
if the required information is set forth clearly (for 
example, by separating it from the promotional material). 
In addition, a consumer may not be required to surrender 
the receipt or that portion containing the required 
disclosures in order to take advantage of a promotion. 

4 Transfer not completed . The receipt requirement does 
not apply to a transfer that is initiated but not completed 
(for example, if the ATM is out of currency or the 
consumer decides not to complete the transfer). 

5. Receipts not furnished due to inadvertent error . If a 
receipt is not provided to the consumer because of a bona 
fide unintentional error, such as when a terminal runs out 
of paper or the mechanism jams, no violation results if the 
financial institution maintains procedures reasonably 
adapted to avoid such occurrences. 

6, Multiple transfers . If the consumer makes multiple 
transfers at the same time, the financial institution may 
document them on a single or on separate receipts. 

Paragraph 9(a)(1) - Amount. 

1 . Disclosure of transaction fee . The required display of 
a fee amount on or at the terminal may be accomplished 
by displaying the fee on a sign at the terminal or on the 
terminal screen for a reasonable duration. Displaying the 
fee on a screen provides adequate notice, as long as a 
consumer is given the option to cancel the transaction 
after receiving notice of a fee. (See §205.16 for the 
notice requirements applicable to ATM operators that 
impose a fee for providing EFT services.) 

2. Relationship between § 205.9<aHlVand § 205.16 . The 
requirements of §§ 205.9(a)(1) and 205.16 are similar but 
not identical. 
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Section 205.9(a)(1) requires that if the 
amount of the transfer as shown on the 
receipt will include the fee, then the fee 
must be disclosed either on a sign or at 
the terminal, or on the terminal screen. 
Section 2 05. 16 requires disclosure both 
on a sign or at the terminal (in a 
prominent and conspicuous location) 
and on the terminal screen. Section 
205.16 permits disclosure on a paper 
notice as an alternative to the on-screen 
disclosure. 

The disclosure of the fee on the receipt 
under § 205.9(a)(1) cannot be used to 
comply with the alternative paper 
disclosure procedure under § 205. 1 6, if 
the receipt is provided at the 
completion of the transaction because, 
pursuant to the statute, the paper notice 
must be provided before the consumer 
is committed to paying the fee. 

Section 205.9(a)(1) applies to any type 
of electronic terminal as defined in 
Regulation E (for example, to POS 
terminals as well as to ATMs), while § 
205.16 applies only to ATMs. 



Paragraph 9(a)(2) - Date. 

1 . Calendar date . The receipt must disclose the calendar 
date on which the consumer uses the electronic terminal. 
An accounting or business date may be disclosed in 
addition if the dates are clearly distinguished. 

Paragraph 9(a)(3) - Type. 

1* Identifying transfer and account . Examples identifying 
the type of transfer and the type of the consumer's account 
include "withdrawal from checking," "transfer from 
savings to checking," or "payment from savings." 

2. Exception . Identification of ?m account is not required 
when the consumer can access only one asset account at 
a particular time or terminal, even if the access device can 
normally be used to access more than one account. For 
example, the consumer may be able to access only one 
particular account at terminals not operated by the 
account-holding institution, or may be able to access only 
one particular account when the terminal is off-line. The 
exception is available even if, in addition to accessing one 
asset account, the consumer also can access a credit line. 

3 . Access to multiple accounts . If the consumer can use 
an access device to make transfers to or from different 



accounts of the same type, the terminal receipt must 
specify which account was accessed, such as "withdrawal 
from checking I" or "withdrawal from checking II." If 
only one account besides the primary checking account 
can be debited, the receipt can identify the account as 
"withdrawal from other account." 

4. Generic descriptions . Generic descriptions may be 
used for accounts that are similar in function, such as 
share draft or NOW accounts and checking accounts. In 
a shared system, for example, when a credit union 
member initiates transfers to or from a share draft account 
at a terminal owned or operated by a bank, the receipt 
may identify a withdrawal from the account as a 
"withdrawal from checking." 

5 - Point-of-sale transactions . There is no prescribed 
terminology for identifying a transfer at a merchant's POS 
terminal. A transfer may be identified, for example, as a 
purchase, a sale of goods or services, or a payment to a 
third party. When a consumer obtains cash from a POS 
terminal in addition to purchasing goods, or obtains cash 
only, the documentation need not differentiate the 
transaction from one involving the purchase of goods. 

Paragraph 9(a)(5) - Terminal location. 

1. Options for identifying terminal . The institution may 
provide either: 



The city, state, or foreign country, and 
the information in ■'.§§ 205.9(a)(5)(i), 
(ii), or(iii), or 

A number or a code identifying the 
terminal. If the institution chooses the 
second option, the code or terminal 
number identifying the terminal where 
the transfer is initiated may be given as 
part of a transaction code. 



n. 



2 ..' Omission of city name . The city may be omitted if the 
generally accepted name (such as a branch name) contains 
the city name. 

3 . Omission of state . The state may be omitted from the 
location information on the receipt if: 

i. All the temiinals owned or operated by 

the financial institution providing the 
statement (or by the system in which it 
participates) are located in that state, or 

ii. All transfers occur at terminals located 

within 50 miles of the financial 
institution's main office. 
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4. Omission of city and state . The city and state may be 
omitted if all the terminals owned or operated by the 
financial institution providing the statement (or by the 
system in which it participates) are located in the same 
city. 

Paragraph 9(a)(5)(i) 

1 . Street address . The address should include number 
and street (or intersection); the number (or intersecting 
street) may be omitted if the street alone uniquely 
identifies the terminal location. 

Paragraph 9(a)(5)(ii) 

1 , Generally accepted name . Examples of a generally 
accepted name for a specific location include a branch of 
the financial institution, a shopping center, or an airport. 



Paragraph 9(a)(5)(iii) 

1 . Name of owner or operator of terminal . Examples of 
an owner or operator of a terminal are a financial 
institution or a retail merchant. 

Paragraph 9(a)(6) -- Third party transfer. 

1. Omission of third-partv name . The receipt need not 
disclose the third-party name if the name is provided by 
the consumer in a form that is not machine readable (for 
example, if the consumer indicates the payee by 
depositing a payment stub into the ATM). If, on the other 
hand, the consumer keys in the identity of the payee, the 
receipt must identify the payee by name or by using a 
code that is explained elsewhere on the receipt. 

2. Receipt as proof of payment . Documentation required 
under the regulation constitutes prima facie proof of a 
payment to another person, except in the case of a 
terminal receipt documenting a deposit 

'9(h\ Periodic statements . 

1 . Periodic cycles . Periodic statements may be sent on a 
cycle that is shorter than monthly. The statements must 
correspond to periodic cycles that are reasonably equal, 
that is, do not vary by more than four days from the 
regular cycle. The requirement of reasonably equal cycles 
does not apply when an institution changes cycles for 
operational or other reasons, such as to establish a new 
statement day or date. 

2. Interim statements . Generally, a financial institution 
must provide periodic statements for each monthly cycle 
in which an EFT occurs, and at least quarterly if a transfer 
has not occurred. Where EFTs occur between regularly- 
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scheduled cycles, interim statements must be provided. 
For example, if an institution issues quarterly statements 
at the end of March, June, September and December, and 
the consumer imtiates a^ 

statement for February must be provided. If an interim 
statement contains interest or rate information, the 
institution must comply with Regulation DD, 12 CFR 

'230.6. ':'■■■;■■'■■; ; ^ 

3. Inactive accounts . A financial institution need not 
send statements to consumers whose accounts are inactive 
as defined by the institution. 

4 Statement pickup . A financial institution may permit; 
but may not require, consumers to pick up their periodic 
statements at the financial institution. 

5. Periodic statements limited to EF T activity. A 
financial institution that uses a passbook as the primary 
means for displaying account activity, but also allows the 
account to be debited electronically, may provide a 
periodic statement requirement that reflects only the EFTs 
and other required disclosures (such as charges, account 
balances, and address and telephone number for 
inquiries). (See § 205.9(c)(l)(i) for the exception 
applicable to preauthorized transfers for passbook 
accounts.) 

6 Codes and accompanying documents . To meet the 
documentation requirements for periodic statements, a 
financial institution may: 

i. Include copies of terminal receipts to 

reflect transfers initiated by the 
consumer at electronic terminals; 

ii. Enclose posting memos, deposit slips, 

and other documents that, together with 
the statement, disclose all the required 
information; 




hi. Use codes for names of third parties or 

terminal locations and explain the 
information to which the codes relate 
on an accompanying document. 

Paragraph 9(b)(1) ~ Transaction information. 

1; Information obtained from others . While financial 
institutions must maintain reasonable procedures to ensure 
the integrity of data obtained from another institution, a 
merchant, or other third parties, verification of each 
transfer that appears on the periodic statement is not 
required. 
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Paragraph 9(b)(l)(i) 

1 • Incorrect deposit amount . If a financial institution 
determines that the amount actually deposited at an ATM 
is different from the amount entered by the consumer, the 
institution need not immediately notify the consumer of 
the discrepancy; The periodic statement reflecting the 
deposit may show either the correct amount of the deposit 
or the amount entered by the consumer along with the 
institution's adjustment. 

Paragraph 9(b)(l)(iii) 

1. Type of transfer. There is no prescribed terminology 
for describing a type of transfer. Placement of the amount 
of the transfer in the debit or the credit column is 
sufficient if other information on the statement, such as a 
terminal location or third-party name, enables the 
consumer to identify the type of transfer. 

Paragraph 9(b)(l)(iv) 

* • Nonpropri etary terminal in network . An institution 
need not reflect on the periodic statement the street 
addresses, identification codes, or terminal numbers for 
transfers initiated in a shared or interchange system at a 
terminal operated by an institution other than the account- 
holding institution. The statement must, however, specify 
the entity that owns or operates the terminal, plus the city 
and state. 

Paragraph 9(b)(l)(v) 

1 • Recurring payments bv government agency . The third- 
party name for recurring payments from federal, state, or 
local governments need not list the particular agency. For 
example, "U.S: gov't" or "N.Y. sal" will suffice. 

2- Consumer as third-party payee . If a consumer makes 
an electronic fund transfer to another consumer, the 
financial institution must identify the recipient by name 
(not just by an account number, for example). 

3. Terminal location/ mird party . A single entry may be 
used to identify both the terminal location and the name of 
the third party to or from whom funds are transferred. For 
example, if a consumer purchases goods from a merchant, 
the name of the party to whom funds are transferred (the 
merchant) and the location of me terminal where the 
transfer is initiated will be satisfied by a disclosure such 
as "XYZ Store, Anytown, Ohio." 

■ 4. : Account-holding institution as third party . Transfers 
to the account-holding institution (by ATM, for example) 
must show the institution as the recipient, unless other 
information on the statement (such as, "loan payment from 



checking") clearly indicates that the payment was to the 
account-holding institution. 

5. Consistenc y in third-party identity . The periodic 
statement must disclose a third-party name as it appeared 
on the receipt, whether it was, for example, the "dba" 
(doing business as) name of the third party or the parent 
corporation's name. 

6. Third-party identity on deposits at electronic terminal 
A financial institution need not identify third parties 
whose names appear on checks, drafts, or similar paper 
instruments deposited to the consumer's account at an 
electronic terminal. 

Paragraph 9(b)(3) -- Fees. 

1 . Disclosure of fees. The fees disclosed may include 
fees for EFTs and for other nonelectronic services, and 
both fixed fees and per-item fees; they may be given as a 
total or may be itemized in part or in full. 

2 * Fees in int erchange system . An account-holding 
institution must disclose any fees it imposes on the 
consumer for EFTs, including fees for ATM transactions 
in an interchange or shared ATM system. Fees for use of 
an ATM impos ed on the consumer by an institution other 
than the account-holding institution and included in the 
amount of the transfer by the terminal-operating 
institution need not be separately disclosed on the 
periodic statement. 

3. Finance charges. The requirement to disclose any fees 
assessed against the account does not include a finance 
charge imposed on the account during the statement 
period. 

Paragraph 9(b)(4) -Account balances. 

*• Opening a nd closing; balances . The opening and 

closing balances must reflect both EFTs and other account 
activity. 



Paragraph 9(b)(5) 
for inquiries. 



Address and telephone number 



1- Telephone number. A single telephone number, 
preceded by the "direct inquiries to" language, will satisfy 
the requirements of § 205.9(b)(5) and (6). 
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Paragraph 9(b)(6) --Telephone number for 
preauthorized transfers 

1 . Telephone number . See comment 9(b)(5)- 1. 

9(c) Exceptions to the periodic statement requirements 
for certain accounts . 

1 . Transfers between accounts . The regulation provides 
an exception from the periodic statement requirement for 
certain intra-institutional transfers between a consumer's 
accounts The financial institution must still comply with 
the applicable periodic statement requirements for any 
other EFTs to or from the account. For example, a 
Regulation E statement must be provided quarterly for an 
account that also receives payroll deposits electronically, 
or for any month in which an account is also accessed by 
a withdrawal at an ATM. 



Paragraph 
accounts. 



9(c)(1) _ Preauthorized transfers to 



1 . Accounts that maybe accessed only bv preauthorized 
transfers to the account . The exception for "accounts that 
may be accessed only by preauthorized transfers to the 
account" includes accounts that can be accessed by means 
other than EFTs, such as checks. If, however, an account 
may be accessed by any EFT other than preauthorized 
credits to the account, such as preauthorized debits or 
ATM transactions, the account does not qualify for the 
exception. 

2. Reversal of direct deposits . For direct-deposit-only 
accounts, a financial institution must send a periodic 
statement at least quarterly. A reversal of a direct deposit 
to correct an error does not trigger the monthly statement 
requirement when the error represented a credit to the 
wrong consumer's account, a duplicate credit, or a credit 
in the wrong amount. (See also comment 2(m)-5.) 

9(dY Documentation for foreign-initiated transfers . 

1 . Foreign-initiated transfers . An institution must make 
a good faith effort to provide all required information for 
foreign-initiated transfers. For example, even if the 
institution is not able to provide a specific terminal 
location, it should identify the country and city in which 
the transfer was initiated. 



SECTION 205.10 -- Preauthorized Transfers 

10(a) Preauthorized transfers to consu mer's account. 

Paragraph 10(a)(1) -- Notice by financial institution 

1 . Content . No specific language is required for notice 
regarding receipt of a preauthorized transfer. Identifying 
the deposit is sufficient; however, simply providing the 
current account balance is not. 

2 Notice of credit . A financial institution may use 
different methods of notice for various types or series of 
preauthorized transfers, and the institution need not offer 
consumers a choice of notice methods. 

3. Positive notice . A periodic statement sent within two 
business days of the scheduled transfer, showing the 
transfer, can serve as notice of receipt. 

4. Negative notice . The absence of a deposit entry (on a 
periodic statement sent within two business days of the 
scheduled transfer date) will serve as negative notice. 

5 Telephone notice . If a financial institution uses the 
telephone notice option, it should be able in most 
instances to verify during a consumer's initial call whether 
a transfer was received. The institution must respond 
within two business days to any inquiry not answered 
immediately. 

6 Phone number for passbook accounts . The financial 
institution may use any reasonable means necessary to 
provide the telephone number to consumers with 
passbook accounts that can only be accessed by 
preauthorized credits and that do not receive periodic 
statements. For example, it may print the telephone 
number in the passbook, or include the number with the 
annual error resolution notice. 

7 Tele phone line availability . To satisfy the readily- 
available standard, the financial institution must provide 
enough telephone lines so that consumers get a reasonably 
prompt response. The institution need only provide 
telephone service during normal business hours. Within 
its primary service area, an institution must provide a 
local or toll-free telephone number. It need not provide a 
toll-free number or accept collect long-distance calls from 
outside the area where it normally conducts business. 

10(b) Written authorization for p reauthorized 
transfers from consumer's account . 

1 ■ Preexisting authorizations . The financial institution 
need not require a new authorization before changing 
from paper-based to electronic debiting when the existing 
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authorization does not specify that debiting is to occur 
electronically or specifies that the debiting will occur by 
paper means. A new authorization also is not required 
when a successor institution begins collecting payments. 

'?,; Authorization obtained by third party . The account- 
holding financial institution does not violate the regulation 
when a third-party payee fails to obtain the authorization 
in writing or fails to give a copy to the consumer; rather, 
it is the third-party payee that is in violation of the 
regulation, 

3. Written authorization for preauthorized transfers . The 
requirement that preauthorized EFTs be authorized by the 
consumer "only by a writing" cannot be met by a payee's 
signing a written authorization on the consumer's behalf 
with only an oral authorization from the consumer. A tape 
recording of a telephone conversation with a consumer 
who agrees to preauthorized debits also does not 
constitute written authorization for purposes of this 
provision. 

4. Use of a confirmation form . A financial instihitirm nr 
designated payee may comply with the requirements of 
this section in various ways. For example, a payee may 
provide the consumer with two copies of a 
preauthorization form, and ask the consumer to sign and 
return one and to retain the second copy. 

5 . Similarly authenticated . The similarly authenticated 
standard permits signed, written authorizations to be 
provided electronically. The writing and signature 
requirements of this section are satisfied by complying 
with me Electronic Signatures in Global and National 
Commerce Act, U.S.C. 7001 efseg,., which defines 
electronic records and electronic signatures. Examples of 
electronic signatures include, but are not limited to, digital 
signatures and security codes. A security code need not 
originate with the account-holding institution. The 
authorization process should evidence the consumer's 
identity and assent to the authorization. The person that 
obtains the authorization must provide a copy of the terms 
of the authorization to me consumer either electronically 
or in paper form. Only the consumer may authorize the 
transfer and not, for example, a third-party merchant on 
behalf of the consumer. 

6. Requirements of an authorization . An authorization is 
valid if it is readily identifiable as such and the terms of 
the preauthorized transfer are clear and readily 
understandable. 

7. Bona fide error . Consumers sometimes authorize 
third-party payees, by telephone or on-line, to submit 
recurring charges against a credit card account. If the 
consumer indicates use of a credit card account when in 



fact a debit card is being used, the payee does not violate 
the requirement to obtain a written authorization if the 
failure to obtain written authorization was not intentional 
and resulted from a bona fide error, and if the payee 
maintains procedures reasonably adapted to avoid any 
such error. If the payee is unable to determine, at the time 
of the authorization, whether a credit or debit card number 
is involved, and later finds that the card used is a debit 
card, the payee must obtain a written and signed or (where 
appropriate) a similarly authenticated authorization as 
soon as reasonably possible, or cease debiting the 
consumer's account. 

10(c) Consumer's right to stop payment 

J;-'/; Stop-pav ment order The financial institution must 
honor an oral stop-payment order made at least three 
business days before a scheduled debit. If the debit item 
is resubmitted, the institution must continue to honor the 
stop-payment order (for example, by suspending all 
subsequent payments to the payee-originator until the 
consumer notifies the institution that payments should 
resume). 

2. Revocation of authorization . Once a financial 
institution has been notified that the consumer's 
authorization is no longer valid, it must block all future 
payments for the particular debit transmitted by the 
designated payee-originator. The institution may not wait 
for the payee-originator to terminate the automatic debits. 
The institution may confirm that the consumer has 
informed the payee-originator of the revocation (for 
example, by requiring a copy of the consumer's revocation 
as written confrrmation to be provided within fourteen 
days of an oral notification). If the institution does not 
receive me required written confirmation within the 
fourteen-day period, it may honor subsequent debits to the 
account; 

10(d) Notice of transfers varying in amount 

Paragraph 10(d)(1) - Notice. 

1 • Preexisting authorizations . A financial institution 
holding the consumer's account does not violate the 
regulation if the designated payee fails to provide notice 
of varying amounts. 

Paragraph 10(d)(2) -Range. 

1. Range . A financial institution or designated payee that 
elects to offer the consumer a specified range of amounts 
for debiting (in lieu of providing the notice of transfers 
varying in amount) must provide an acceptable range that 
could be anticipated by the consumer. For example, if the 
transfer is for payment of a gas bill, an appropriate range 
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might be based on the highest bill in winter and the lowest 
bill in summer. 

10(e^ Compulsory use . 

Paragraph 10(e)(1) - Credit. 

1 . Loan payments . Creditors may not require repayment 
of loans by electronic means on a preauthorized, recurring 
basis. A creditor may offer a program with a reduced 
annual percentage rate or other cost-related incentive for 
an automatic repayment feature, provided the program 
with the automatic payment feature is not the only loan 
program offered by the creditor for the type of credit 
involved. Examples include: 

i. Mortgages with graduated payments in 

which a pledged savings account is 
automatically debited during an initial 
period to supplement the monthly 
payments made by the borrower. 

ii. Mortgage plans calling for 

preauthorized biweekly payments that 
are debited electronically to the 
consumer's account and produce a 
lower total finance charge. 

2. Overdraft . A financial institution may require the 
automatic repayment of an overdraft credit plan even if 
the overdraft extension is charged to an open-end account 
that may be accessed by the consumer in ways other than 
by overdrafts. 



Paragraph 10(e)(2) 
benefit. 



Employment or government 



1. Payroll . An employer (including a financial 
institution) may not require its employees to receive their 
salary by direct deposit to any particular institution. An 
employer may require direct deposit of salary by 
electronic means if employees are allowed to choose the 
institution that will receive the direct deposit. 
Alternatively, an employer may give employees the choice 
of having their salary deposited at a particular institution 
(designated by the employer) or receiving their salary by 
another means, such as by check or cash. 

SECTION 205.1 1 --Procedures For Resolving Errors 

1 1 (aV Definition of error . 

1. Terminal location . With regard to deposits at an ATM, 
a consumer's request for the terminal location or other 
information triggers the error resolution procedures, but 



the financial institution need only provide the ATM 
location if it has captured that information. 

2. Verifying an account debit or credit ^ If the consumer 
contacts the financial institution to ascertain whether a 
payment (for example, in a home-banking or bill-payment 
program) or any other type of EFT was debited to the 
account, or whether a deposit made via ATM, 
preauthorized transfer, or any other type of EFT was 
credited to the account; without asserting an error, the 
error resolution procedures do not apply. 

3. Loss or theft of access device . A financial institution 
is required to comply with the error resolution procedures 
when a consumer reports the loss or theft of an access 
device if the consumer also alleges possible unauthorized 
use as a consequence of the loss or theft. 

4 Error asserted after account closed . The financial 
institution must comply with the error resolution 
procedures when a consumer properly asserts an error, 
even if the account has been closed. 

5. Request for documentation or information . A request 
for documentation or other information must be treated as 
an error unless it is clear that the consumer is requesting 
a duplicate copy for tax or other record-keeping purposes. 

1 iflrt Notice of error from consumer . 
Paragraph 11(b)(1) -Timing; contents. 

1 . Content of error notice . The notice of error is effective 
even if it does not contain the consumer's account number, 
so long as the financial institution is able to identify the 
account in question. For example, the consumer could 
provide a Social Security number or other unique means 
of identification. 

2. Investigation pending receipt of information . While a 
financial institution may request a written, signed 
statement from the consumer relating to a notice of error, 
it may not delay initiating or completing an investigation 
pending receipt of the statement. 

3. Statement held for consumer . When a consumer has 
arranged for periodic statements to be held until picked 
up, the statement for a particular cycle is deemed to have 
been transmitted on the date the financial institution first 
makes the statement available to the consumer. 

4. Failure to provide statement . When a financial 
institution fails to provide the consumer with a periodic 
statement, a request for a copy is governed by this section 
if the consumer gives notice within 60 days from the date 
on which the statement should have been transmitted. 
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5. Discovery of error bv institution . The error resolution 
procedures of this section apply when a notice of error is 
received from the consumer, and not when the financial 
institution itself discovers and corrects an error. 

6.: Notice at particular phone number or address . A 
financial institution may require the consumer to give 
notice only at the telephone number or address disclosed 
by the institution, provided the institution maintains 
reasonable procedures to refer the consumer to the 
specified telephone number or address if the consumer 
attempts to give notice to the institution in a different 
manner. 

Paragraph 11(b)(2) -Written confirmation. 

1 ■ Written confirmation-of-error notice . If the consumer 
sends a written confirmation of error to the wrong 
address, the financial institution must process the 
confirmation through normal procedures. But the 
institution need not provisionally credit the consumer's 
account if the written confirmation is delayed beyond 10 
business days in getting to the right place because it was 
sent to the wrong address. 

life) Time limits and extent of investigation . 

1. Notice to consumer . Unless otherwise indicated in this 
section, the financial institution may provide the required 
notices to the consumer either orally or in writing. 

2. Written confirmation of oral notice . A financial 
institution must begin its investigation promptly upon 
receipt of an oral notice. It may not delay until it has 
received a written confirmation. 

3. Charges for error resolution . If a billing error 
occurred, whether as alleged or in a different amount or 
manner, the financial institution may not impose a charge 
related to any aspect of the error-resolution process 
(including charges for documentation or investigation). 
Since the act grants the consumer error-resolution rights, 
the institution should avoid any chilling effect on the 
good-faith assertion of errors that might result if charges 
are assessed when no billing error has occurred. 

4. Correction without investigation . A financial 
institution may make, without investigation, a final 
correction to a consumer's account in the amount or 
manner alleged by the consumer to be in error, hut must 
comply with all other applicable requirements of § 
205.11. 

5. Correction notice . A financial institution may include 
the notice of correction on a periodic statement that is 
mailed or delivered within the 1 0-business-day or 45- 



calendar-day time limits and that clearly identifies the 
correction to the consumer's account. The institution must 
determine whether such a mailing will be prompt enough 
to satisfy the requirements of this section, taking into 
account the specific facts involved. 

6. Correction of an error . If the financial institution 
determines an error occurred, within either the 10-day or 
45-day period, it must correct the error (subject to the 
liabilityprovisions of sections 205 .6(a) and (b)) including, 
where applicable, the crediting of interest and the 
refunding of any fees imposed by the institution. In a 
combined credit/EFT transaction, for example, the 
institution must refund any finance charges incurred as a 
result of the error. The institution need not refund fees 
that would have been imposed whether or not the error 
occurred. 

7r Extent of required investigation . A financial institution 
complies with its duty to investigate, correct, and report 
its determination regarding an error described in § 
205.1 l(a)(l)(vii) by transmitting the requested 
information, clarification, or documentation within the 
time limits set forth in paragraph (c) of this section. If the 
institution has provisionally credited the consumer's 
account in accordance with paragraph (c)(2) of this 
section, it may debit the amount upon transmitting the 
requested information, clarification, or documentation. 

Paragraph 11 (c)(2)(i) 

A * Compliance with all requirements . Financial 
institutions exempted from provisionally crediting a 
consumer's account under § 205.11(c)(2)(i)(A) and (B) 
must still comply with all other requirements of the 
section. 

Paragraph 11(c)(3) - Extension of time periods 

V- FQS debit card transactions . The extended deadlines 
for investigating errors resulting from POS debit card 
transactions apply to all debit card transactions, including 
those for cash only, at merchants' POS terminals, and also 
including mail and telephone orders. The deadlines do 
not apply to transactions at an ATM, however, even 
though the ATM may be in a merchant location. 

Paragraph 1 1(c)(4) -- Investigation 

1. Third parties . When information or documentation 
requested by the consumer is in the possession of a third 
party with whom the financial institution does not have an 
agreement, the institution satisfies the error resolution 
requirement by so advising the consumer within the 
specified time period. 
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2. Scope of investigation . When an alleged error involves 
a payment to a third party under the financial institution's 
telephone bill-payment plan, a re view of the institution's 
own records is sufficient, assuming no agreement exists 
between the institution and the third party concerning the 
bill-payment service. 

3 POS transfers . When a consumer alleges an error 
involving a transfer to a merchant via a POS terminal, the 
institution must verify the information previously 
transmitted when executing the transfer. For example, the 
financial institution may request a copy of the sales 
receipt to verify that the amount of the transfer correctly 
corresponds to the amount of the consumer's purchase. 

4. Agreement . An agreement that a third party will honor 
an access device is an agreement for purposes of this 
paragraph. A financial institution does not have an 
agreement for purposes of § 205.1 l(c)(4)(ii) solely 
because it participates in transactions that occur under the 
federal recurring payments programs, or that are cleared 
through an ACH or similar arrangement for the clearing 
and settlement of fund transfers generally, or because it 
agrees to be bound by the rules of such an arrangement. 



section. It may, however, impose any normal transaction 
or item fee that is unrelated to an overdraft resulting from 
the debiting. If the account is still overdrawn after five 
business days, me institution may impose the fees or 
finance charges to which it is entitled, if any, under an 
overdraft credit plan. 

11(e) Reassertion of error . 

1 . Withdrawal of error; right to reassert . The financial 
institution has no further error resolution responsibilities 
if the consumer voluntarily withdraws the notice alleging 
an error. A consumer who has withdrawn an allegation of 
error has the right to reassert the allegation unless the 
financial institution had already complied with all of the 
error resolution requirements before the allegation was 
withdrawn. The consumer must do so, however, within 
the original 60-day period. 

SECTION 205.12 -- Relation to Other Laws 

12(a) Relation to Truth in Lending . 

1. Determining applicable regulation . 



11(d) Procedures if financial institution determines no i For transactions involving access 

error or different error occurred . r devices that also function as credit 

cards, whether Regulation E or 
1 . Error different from that alleged . When a financial Regulation Z (12 C.F.R. part 226) 

institution determines that an error occurred in a manner applies depends on the nature of the 

or amount different from that described by the consumer, transaction. For example, if the 

it must comply with the requirements of both paragraphs transaction solely involves an extension 

(c) and (d) of this section, as relevant. The institution may of credit, and does not include a debit 

give the notice of correction and the explanation to a checking account (or other 

separately or in a combined form. consumer asset account), the liability 

limitations and error resolution 
Paragraph 11(d)(1)- Written explanation. requirements ofRegulationZ apply. If 

the transaction debits a checking 
1. Request for documentation . When a consumer account only (with no credit extended), 

requests copies of documents, the financial institution the provisions of Regulation E apply, 

must provide the copies in an understandable form. If an If the transaction debits a checking 

institution relied on magnetic tape it must convert the account but also draws on an overdraft 

applicable data into readable form, for example, by line of credit attached to the account, 

printing it and explaining any codes. Regulation E's liability limitations 

apply, in addition to §§ 226.13(d) and 
Paragraph 11(d)(2) — Debiting provisional credits (g) of Regulation Z (which apply 

because of the extension of credit 

1. Alternative procedure for debiting of credited funds . associated with the overdraft feature on 
The financial institution may comply with the the checking account). If a consumer's 
requirements of this section by notifying the consumer access device is also a credit card and 
that the consumer's account will be debited five business the device is used to make 
days from the transmittal of the notification, specifying unauthorized withdrawals from a 
the calendar date on which the debiting will occur. checking account, but also is used to 

obtain unauthorized cash advances 

2. Fees for overdrafts . The financial institution may not directly from a line of credit that is 
impose fees for items it is required to honor under this separate from the checking account, 
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both Regulation E and Regulation Z 
apply. 

The following examples illustrate these 
principles: 

(A) A consumer has a card that 
can be used either as a credit 
card or a debit card. When 
used as a debit card, the card 
draws on the consumer's 
checking account. When used 
as a credit card, the card 
draws only on a separate line 
of credit. If the card is stolen 
and used as a credit card to 
make purchases or to get cash 
advances at an ATM from the 
line of credit, the liability 
limits and error resolution 
provisions of Regulation Z 
apply; Regulation E does not 
apply. 

(B) In the same situation, if the 
card is stolen and is used as a 
debit card to make purchases 
or to get cash withdrawals at 
an ATM from the checking 
account, the liability limits 
and error resolution 
provisions of Regulation E 
apply; Regulation Z does not 
apply. 

(C) In the same situation, assume 
the card is stolen and used as 
both a debit card and as a 
credit card; for example, the 
thief makes some purchases 
using the card as a debit card, 
and other purchases using the 
card as a credit card. Here, 
the liability limits and error 
resolution provisions of 
Regulation E apply to the 
unauthorized transactions in 
which the card was used as a 
debit card, and the 
corresponding provisions of 
Regulation Z apply to the 
unauthorized transactions in 
which the card was used as a 
credit card. 



(D) 



Assume a somewhat different 
type of card, one that draws 
on the consumer's checking 
account and can also draw on 
an overdraft line of credit 
attached to the checking 
account. There is no separate 
line of credit, only the 
overdraft line, associated with 
the card. In this situation, if 
the card is stolen and used, 
the liability limits and the 
error resolution provisions of 
Regulation E apply. In 
addition, if the use of the card 
has resulted in accessing the 
overdraft line of credit, the 
error resolution provisions of 
§ 226.13(d) and (g) of 
Regulation Z also apply, but 
not the other error resolution 
provisions of Regulation Z. 



2. Issuance rules . For access devices that also constitute 
credit cards, the issuance rules of Regulation E apply if 
the only credit feature is a preexisting credit line attached 
to the asset account to cover overdrafts (or to maintain a 
specified minimum balance). Regulation Z rules apply if 
there is another type of credit feature, for example, one 
permitting direct extensions of credit that do not involve 
the asset account. 

12(b) Preemption of inconsistent state laws . 

1. Specific determinations . The regulation prescribes 
standards for determining whether state laws that govern 
EFTs are preempted by the act and the regulation. A state 
law that is inconsistent may be preempted even if the 
Board has not issued a determination. However, nothing 
in § 205 . 1 2(b) provides a financial institution with 
immunity for violations of state law if the institution 
chooses not to make state disclosures and the Board later 
determines that the state law is not preempted. 

2. Preemption determination . The Board determined that 
certain provisions in the state law of Michigan are 
preempted by the federal law, effective March 30, 1981: 



Definition of unauthorized use. 
Section 5(4) is preempted to the extent 
that it relates to the section of state law 
governing consumer liability for 
unauthorized use of an access device. 

Consumer liability for unauthorized use 
of an account. Section 14 is 
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m. 



IV. 



inconsistent with § 205.6 and is less 
protective of the consumer than the 
federal law. The state law places 
liability on the consumer for the 
unauthorized use of an account in cases 
involving the consumer's negligence. 
Under the federal law, a consumer's 
liability for unauthorized use is not 
related to the consumer's negligence 
and depends instead on the consumer's 
promptness in reporting the loss or 
theft of the access device. 

Error resolution. Section 15 is 
preempted because it is inconsistent 
with § 205. 1 1 and is less protective of 
the consumer than the federal law. The 
state law allows financial institutions 
up to 70 days to resolve errors, whereas 
the federal law generally requires 
errors to be resolved within 45 days. 

Receipts and periodic statements. 
Sections 17 and 18 are preempted 
because they are inconsistent with § 
205 .9. The state provisions require a 
different disclosure of information than 
does the federal law. The receipt 
provision is also preempted because it 
allows the consumer to be charged for 
receiving a receipt if a machine cannot 
furnish one at the time of a transfer. 



SECTION 205.13 
Record Retention 



Administrative Enforcement; 



13rt>Y Record retention . 

1. Requirements . A financial institution need not retain 
records that it has given disclosures and documentation to 
each consumer; it need only retain evidence 
demonstrating that its procedures reasonably ensure the 
consumers' receipt of required disclosures and 
documentation. 

SECTION 205.14 -- Electronic Fund Transfer Service 
Provider Not Holding Consumer's Account 

l4faY Electronic fund transfer service providers 
subject to regulation . 

1 . Applicability . This section applies only when a service 
provider issues an access device to a consumer for 
initiating transfers to or from the consumer's account at a 
financial institution and the two entities have no 
agreement regarding this EFT service. If the service 



provider does not issue an access device to the consumer 
for accessing an account held by another institution, it 
does not qualify for the treatment accorded by this 
section. For example, this section does not apply to an 
institution that initiates preauthorized payroll deposits to 
consumer accounts on behalf of an employer. By 
contrast, this section can apply to an institution that issues 
a code for initiating telephone transfers to be carried out 
through the ACH from a consumer's account at another 
institution. This is the case even if the consumer has 
accounts at both institutions. 

2. ACH agreements . The ACH rules generally do not 
constitute an agreement for purposes of this section. 
However, an ACH agreement under which members 
specifically agree to honor each other's debit cards is an 
"agreement," and thus this section does not apply. 

14(b) Compliance by electronic fund transfer service 
provider . 

1 . Liability . The service provider is liable for 
unauthorized EFTs that exceed limits on the consumer's 
liability under §205.6. 

Paragraph 14(b)(1) - Disclosures and documentation. 

1. Periodic statements from electronic fund transfer 
service provider . A service provider that meets the 
conditions set forth in this paragraph does not have to 
issue periodic statements. A service provider that does 
not meet the conditions need only include on periodic 
statements information about transfers initiated with the 
access device it has issued. 

Paragraph 14(b)(2) -- Error resolution. 

1 . Error resolution . When a consumer notifies the service 
provider of an error, the EFT service provider must 
investigate and resolve the error in compliance with § 
205.11 as modified by paragraph 14(b)(2). If an error 
occurred, any fees or charges imposed as a result of the 
error, either by the service provider or by the account- 
holding institution (for example, overdraft or dishonor 
fees) must be reimbursed to the consumer by the service 
provider. 

14(c) Compliance bv account-holding institution . 
Paragraph 14(c)(1) 

1 ;■ Periodic statements from account-holding institution . 
The periodic statement provided by the account-holding 
institution need only contain the information required by 

§ 205.9(b)(1). 
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SECTION 205.16 - Disclosures at Automated Teller 
Machines 

16(b) General. 

Paragraph 16(b)(1) 

1. Specific notices . An ATM operator that imposes a fee 
for a specific type of transaction such as a cash 
withdrawal, but* not a balance inquiry, may provide a 
general statement that a fee will be imposed for providing 
EFT services or may specify the type of EFT for which a 
fee is imposed. 

SECTION 205.17 - Requirements for Electronic 
Communication 

17(b) General Rule . 

1. Relationship to the E-Sign Act . The R-Sian Art 
authorizes the use of electronic disclosures. It does not 
affect any requirement imposed under this part other than 
a provision that requires disclosures to be in paper form, 
and it does not affect the content or timing of disclosures. 
Electronic disclosures are subject to the regulation's 
format, timing, and retainability rules and the clear and 
readily understandable standard. For example, to satisfy 
the clear and readily understandable standard for 
disclosures, electronic disclosures must use visual text 

2. Clear and readily understandable standard . A financial 
institution must provide electronic disclosures using a 
clear and readily understandable format. Also, in 
accordance with the E-Sign Act: 

i. The institution must disclose the 

requirements for accessing and 
retaining disclosures in that format; 

ii. The consumer must demonstrate the 

ability to access the information 
electronically and affirmatively consent 
to the electronic delivery; and 

iii. The institution must provide the 

disclosures in accordance with the 
specified requirements. 

3. Timing and effective delivery when a consumer signs 
up for EFT service on-line . When a consumer contracts 
for an EFT service on the Internet and will be able 
immediately to initiate a fund transfer, a financial 
institution satisfies the timing requirements under this part 
if, at the time the consumer contracts for the service or 
before the first transfer is made, the disclosures 
automatically appear on the screen, even if multiple 



screens are required to view the entire disclosure. Or a 
financial institution may provide a link to electronic 
disclosures, as long as consumers cannot bypass the link 
and they are required to access the disclosures before 
initiating the first transfer. The institution is not required 
to confirm that the consumer has read the disclosures. 

4. Timing and effective delivery for disclosures provided 
periodically . Disclosures provided by e-mail are timely 
based on when the disclosures are sent. Disclosures 
posted at an Internet web site, such as periodic statements 
or change-in-terms and other notices, are timely when the 
financial institution has both made the disclosures 
available and sent a notice alerting the consumer that the 
disclosures have been posted. For example, under § 
205.8(a), institutions offering accounts with EFT services 
must provide a change-in-terms notice to consumers at 
least 21 days in advance of certain changes. For a 
change-in-terms notice posted on the Internet, an 
institution must both post the notice and notify consumers 
of its availability at least 2 1 days in advance of the 
change. 

5. Retainability of disclosures /Financial institutions 
satisfy the requirement that disclosures be in a form that 
the consumer may keep if electronic disclosures are 
delivered in a format that is capable of being retained 
(such as by printing or storing electronically). The format 
must also be consistent with the information required to 
be provided under section 101(c)(l)(C)(i) of the E-Sign 
Act about the hardware and software requirements for 
accessing and retaining electronic disclosures. 

6. Disclosures provided on financial institution's 
equipment , A financial institution that controls the 
equipment providing electronic disclosures to consumers 
(for example, an ATM or computer terminal in a financial 
institution's lobby) must ensure that the equipment 
satisfies the regulation's requirements to provide timely 
disclosures in a clear and readily understandable format 
and in a form that the consumer may keep. For example, 
if disclosures are required at the time of an on-line 
transaction, the disclosures must be sent to the consumer's 
e-mail address or must be made available at another 
location such at the financial institution's Internet web 
site, unless the financial institution provides a printer that 
automatically prints the disclosures. 

17(c) Address or location to receive electronic 
communication . 

Paragraph 17(c)(1) 

1. Electronic address . A consumer's filerrrnniV aHrlr^ge 
is an e-mail address that is not limited to receiving 
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communications transmitted solely by the financial 
institution. 

Paragraph 17(c)(2) 

1 . Identifying account involved . A financial institution 
may identify a specific account in a variety of ways and is 
not required .to identify an account by reference to the 
account number. For example, where the consumer has 
only one checking account, and no confusion would 
result, the institution may refer to "your checking 
account." If the consumer has two checking accounts, the 
institution may, for example, differentiate accounts based 
on names for different checking account programs or by 
using a truncated account number. 

2. 90-day rule . The actual disclosures provided to the 
consumer must be available for at least 90 days, but the 
financial institution has discretion to determine whether 
they should be available at the same location for the entire 
period. 

17(d) Redelivery . 

1. E-mail returned as undeliverable . If an e-mail to the 
consumer (containing an alert notice or other disclosure) 
is returned as undeliverable, the redelivery requirement is 
satisfied if, for example, the institution sends the 
disclosure to a different e-mail address or postal address 
that the institution has on file for the consumer. Sending 
the disclosure a second time to the same electronic 
address is not sufficient if the institution has a different 
address for the consumer on file. 



205. 14(b)(l)(ii) and 205. 1 5(d)(7) and (d)(2). The use of 
appropriate clauses in making disclosures will protect a 
financial institution from liability under sections 915 and 
916 of the act provided the clauses accurately reflect the 
institution's EFT services. 

3. Altering the clauses . Financial institutions may use 
clauses of their own design in conjunction with the 
Board's model clauses. The inapplicable words or 
portions of phrases inparentheses should fee deleted. The 
underscored catchlines are not part of the clauses and 
need not be used. Financial institutions may make 
alterations, substitutions, or additions in the clauses to 
reflect the services offered, such as technical changes 
(including the substitution of a tradename' for the word 
"card," deletion of inapplicable services, or substitution of 
lesser liability limits). Several of the model clauses 
include references to a telephone number and address. 
Where two or more of these clauses are used in a 
disclosure, the telephone number and address may be 
referenced and need not be repeated. 

■ 3 . ■ Supplement II to Part 205 is removed. 

By order of the Board of Governors of the Federal 
Reserve System, acting through the Secretary of the Board 
under delegated authority, April 19, 1996. 

William W. Wiles 

Secretary of the Board 

[FR Doc. 96-00000 Filed 00-00-96; 8:45 am] 

BILLING CODE 6210-01-P 



17(e) Persons other than financial institutions . 

1 . Electronic disclosures . Entities other than financial 
institutions, such as merchants, are subject to certain 
provisions of Regulation E, including §§ 205.10(b) and 
(d). These entities too may use electronic communication 
to provide disclosures required to be in writing. 

APPENDIX A - Model Disclosure Clauses and Forms 

1. Review of forms . The Board will not review or 
approve disclosure forms or statements for financial 
institutions. However, the Board has issued model 
clauses for institutions to use in designing their 
disclosures. If an institution uses these clauses accurately 
to reflect its service, the institution is protected from 
liability for failure to make disclosures in proper form. 



2. Use of the forms . The appendix contains model 
disclosure clauses for optional use by financial institutions 
to facilitate compliance with the disclosure requirements 
of §§ 205.5(b)(2) and (b)(3), 205.6(a), 205.7, 205.8(b), 
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ELECTRONIC FUND 
TRANSFERACT 

Section 901 Short Title 
Section 902 Findings and Purpose 
Section 903 Definitions 
Section 904 Regulations 



SECTION 901— Short Title 

This title may be cited as the "Electronic Fund Transfer 
Act". 

[15 USC 1693 note] 

SECTION 902— Findings and Purpose 



Section 905 Terms and Conditions of 
Transfers 

Section 906 Documentation of Transfers; 
Periodic Statements 

Section 907 Preauthorized Transfers 

Section908 Error Resolution 

Section 909 Consumer Liability for Unauthorized 
Transfers 

Section 910 Liability of Financial Institutions 

Section 911 Issuance of Cards or Other Means 
of Access 

Section 9 12 Suspension of Obligations 

Section 9 1 3 Compulsory Use of Electronic Fund 
Transfers 

Section 914 Waiver of Rights 

Section 915 Civil Liability 

Section 916 Criminal Liability 

Section 917 Administrative Enforcement 

Section 918 Reports to Congress 

Section 919 Relation to State Laws 

Section 920 Exemption for State Regulation 

Section 921 Effective Date 

15 USC 1693 et seq.; 92 Stat. 3728; Pub. L. 
95-630, Financial Institutions 

Regulatory and Interest Rate Control Act, Title 
XX (November 10, 1978) 



(a) The Congress finds that the use of electronic 
systems to transfer funds provides the potential for 
substantial benefits to consumers. However, due to 
the unique characteristics of such systems, the 
application of existing consumer protection 
legislation is unclear, leaving the rights and 
liabilities of consumers, financial institutions, and 
intermediaries in electronic fund transfers 
undefined. 

(b) It is the purpose of this title to provide a basic 
framework establishing the rights, liabilities, and 
responsibilities of participants in electronic fund 
transfer systems .The primary objective of this title, 
however, is the provision of individual consumer 
rights. 

[15USCi693.] 

SECTION 903— Definitions 
As used in this title— 

(1) the term " accepted card or other means of access " 
means a card, code, or other means of access to a 
consumer's account for the purpose of initiating 
electronic fund transfers when the person to whom 
such card or other means of access was issued has 
requested and received or has signed or has used, or 
authorized another to use, such card or other means 
of access for the purpose of transferring money 
between accounts or obtaining money, property, 
labor, or services; 

(2) the term " account " means a demand deposit, 
savings deposit, or other asset account (other than 
an occasional or incidental credit balance in an 
open end credit plan as defined in section 1 03(1) of 
this Act), as described in regulations of the Board, 
established primarily for personal, family, or 
household purposes, but such term does not include 
an account held by a financial institution pursuant 
to a bona fide trust agreement; 

(3) the term " Board " means the Board of Governors of 
the Federal Reserve System: 

(4) the term " business day " means any day on which 
the offices of the consumer's financial institution 
involved in an electronic fund transfer are open to 
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the public for carrying on substantially all of its 
business functions; 

(5) the term " consumer " means a natural person; 

(6) the term " electronic fund transfer " means any 
transfer of funds, other than a transaction originated 
by check, draft, or similar paper instrument, which 
is initiated through an electronic terminal, 
telephonic instrument, or computer or magnetic 
tape so as to order, instruct, or authorize a financial 
institution to debit or credit an account. Such term 
includes, but is not limited to, point-of-sale 
transfers, automated teller machine transactions, 
direct deposits or withdrawals of funds, and 
transfers initiated by telephone . Such term does not 
include— 



(A) any check guarantee or authorization service 
which does not directly result in a debit or 
credit to a consumer's account; 

(B) any transfer of funds, other than those 
processed by automated clearinghouse, made 
by a financial institution on behalf of a 
consumer by means of a service that transfers 
funds held at either Federal Reserve banks or 
other depository institutions and which is not 
designed primarily to transfer funds on 
behalf of a consumer; 

(C) any transaction the primary purpose of which 
is the purchase or sale of securities or 
commodities through a broker-dealer 
registered with or regulated by the Securities 
and Exchange Commission; 

(D) any automatic transfer from a savings 
account to a demand deposit account 
pursuant to an agreement between a 
consumer and a financial institution for the 
purpose of covering an overdraft or main- 
taining an agreed upon minimum balance in 
the consumer's demand deposit account; or 

(E) any transfer of funds which is initiated by a 
telephone conversation between a consumer 
and an officer or employee of a financial 
institution which is not pursuant to a 
prearranged plan and under which periodic 
or recurring transfers are not contemplated; 
as determined under regulations of the 
Board; 



(7) the term " electronic terminal " means an electronic 
device, other than a telephone operated by a 
consumer, through which a consumer may initiate 
an electronic fund transfer. Such term includes but 
is not limited to, point-of-sale terminals, automated 
teller machines, and cash dispensing machines; 



(8) the term " financial institution " means a State or 
National bank, a State or Federal savings and loan 
association, a mutual savings bank, a State or 
Federal credit union, or any other person who, 
directly or indirectly, holds an account belonging to 
a consumer; 

(9) the term " preauthorized electronic fund transfer " 
means an electronic fund transfer authorized in 
advance to recur at substantially regular intervals; 

(10) the term " State " means any State, territory, or 
possession of the United States, the District of 
Columbia, the Commonwealth of Puerto Rico, or 
any political subdivision of any of the foregoing; 
and 

(1.1) the term " unauthorized electronic fund transfer " 
means an electronic fund transfer from a 
consumer's account initiated by a person other than 
the consumer without actual authority to initiate 
such transfer and from which the consumer receives 
no benefit, but the term does not include any 
electronic fund transfer (A) initiated by a person 
.■'other than the cons 
card, code, or other means of access to such 
consumer's account by such consumer, unless the 
consumer has notified the financial institution 
involved that transfers by such other person are no 
longer authorized, (B) initiated with fraudulent 
intent by the consumer or any person acting in 
concert with the consumer, or (C) which constitutes 
an error committed by a financial institution. 

[15 USC 1693a.] 
SECTION 904— Regulations 

(a) The Board shall prescribe regulations to carry out 
the purposes of this title. In prescribing such 
regulations, the Board shall: 

(1) consult with the other agencies referred to in 
section 917 and take into account, and allow 
for, the continuing evolution of electronic 
banking services and the technology utilized 
in such services, 

(2) prepare an analysis of economic impact 
which considers the cost and benefits to 
financial institutions, consumers, and other 
users of electronic fund transfers, including 
the extent to which additional 
documentation, reports, records, or other 
paper work would be required, and the 
effects upon competition in the provision of 
electronic banking services among large and 
small financial institutions and the 
availability of such services to different 
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classes of consumers, particularly low 
income consumers, 

(3) to the extent practicable, the Board shall 
demonstrate that the consul 

the proposed regulations outweigh the 
compliance costs imposed upon consumers 
and financial institutions, and 

(4) any proposed regulations and accompanying 
analyses shall be sent promptly to Congress 
by the Board. 

(b) The Board shall issue model clauses for optional 
use by financial institutions to facilitate compliance 
with the disclosure requirements of section 905 and 
to aid consumers in understanding the rights and 
responsibilities of participants in electronic fund 
transfers by utilizing readily understandable 
language. Such model clauses shall be adopted after 
notice duly given in the Federal Register and 
opportunity for public comment in accordance with 
section 553 of title 5, United States Code. With 
respect to the disclosures required by section 
905(a)(3) and (4), the Board shall take account of 
variations in the services and charges under 
different electronic fund transfer systems and, as 
appropriate, shall issue alternative model clauses 
for disclosure of these differing account terms. 

(c) Regulations prescribed hereunder may contain such 
classifications, differentiations, or other provisions, 
and may provide for such adjustments and 
exceptions for any class of electronic fund 
transfers, as in the judgment of the Board are 
necessary or proper to effectuate the purposes of 
this title, to prevent circumvention or evasion 
thereof, or to facilitate compliance therewith. The 
Board shall by regulation modify the requirements 
imposed by this title on small financial institutions 
if me Board determines that such modifications are 
necessary to alleviate any undue compliance burden 
on small financial institutions and such modifi- 
cations are consistent with the purpose and 
objective of this title. 

(d) Applicability to service providers other than certain 
financial institutions. 

(1) If electronic fund transfer services are made 
available to consumers by a person other 
than a financial institution holding a 
consumer's account, the Board shall, by 
regulation, assure that the disclosures, 
protections, responsibilities, and remedies 
created by this title are made applicable to 
such persons and services. 

(2) (A) The disclosures, protections, 

responsibilities, and remedies 
established under this title, and any 



regulation prescribed or order issues by 
the Board in accordance with this title, 
shall not apply to any electronic benefit 
transfer program established under 
State or local law or administered by a 
State or local government 

(B) Subparagraph (A) shall not apply with 
respect to any electronic funds transfer 
under an electronic benefit transfer 
program for deposits directly into a 
consumer account held by the recipient 
ofthe benefit 

(C) No provision of this paragraph may be 
construed as - 

(i) affecting or altering the 
protections otherwise 
applicable with respect to 
benefits established by Federal, 
State, or local law; or 

(ii) otherwise superseding the 
application of any State or local 
law. 

(D) For purposes of this paragraph, the 
term "electronic benefit transfer 
program" - 

(i) means a program under which a 
government agency distributes 
needs-tested benefits by 
establishing accounts to be 
accessed by recipients 
electronically, such as through 
automated teller machines, or 
point-of-sale terminals; and 

(ii) does not include employment 
related payments, including 
salaries and pension, retirement; 
or unemployment benefits 
established by Federal, State, or 
local governments. 

(3) Fee Disclosures at Automated Teller 
Machines. 



(A) In general, the regulations prescribed 
under paragraph (1) shall require any 
automated teller machine operator who 
imposes a fee on any consumer for 
providing host transfer services to such 
consumer to provide notice in 
accordance with subparagraph (B) to 
the consumer (at the time the service is 
provided) of 
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(i) the fact that a fee is imposed by 
such operator for providing the 
service; and 

(ii) the amount of any such fee. 

(B) Notice requirements. 

(i) On the Machine. The notice 
required under clause (i) of 
subparagraph (A) with respect 
to any fee described in such 
subparagraph shall be posted in 
a prominent and conspicuous 
location on or at the automated 
teller machine at which the 
electronic fund transfer is 
initiated by the consumer. 

(ii) On the Screen. The notice 
required under clauses (i) and 
(ii) of subparagraph (A) with 
respect to any fee described in 
such subparagraph shall appear 
on the screen of the automated 
teller machine, or on a paper 
notice issued from such 
machine, after the transaction is 
initiated and before the 
consumer is irrevocably 
committed to completing the 
transaction, except that during 
the period beginning on the date 
of the enactment of the Gramm- 
Leach-Bliley Act and ending on 
December 31, 2004, this clause 
shall not apply to any 
automated teller machine that 
lacks the technical capability to 
disclose the notice on the screen 
or to issue a paper notice after 
the transaction is initiated and 
before the consumer is 
irrevocably committed to 
completing the transaction. 

(C) Prohibition on Fees Not Properly 
Disclosed and Explicitly Assumed by 
Consumer. No fee may be imposed by 
any automated teller machine operator 
in connection with any electronic fund 
transfer initiated by a consumer for 
which a notice is required under 
subparagraph (A) unless: 

(i) the consumer receives such 
notice in accordance with 
subparagraph (B); and 

(ii) the consumer elects to continue 
in the manner necessary to 



effect the transaction after 
receiving such notice. 

(D) Definitions. For purposes of this 
paragraph, the following definitions 
shall apply: 

(i) Automated Teller Machine 
Operator. The term 'automated 
teller machine operator' means 
anyperson who 

(I) operates an automated, 
teller machine at which 
consumers initiate 
electronic fund transfers; 
and 

(II) is not the financial 
institution that holds the 
account of such 
consumer from which the 

'.■.;'.'■.■■. //.transfer is made.. ; 

(ii) Electronic Fund Transfer. The 
term 'electronic fund transfer' 
includes a transaction that 
involves a balance inquiry 
initiated by a consumer in the 
same manner as an electronic 
fund transfer, whether or not the 
consumer initiates a transfer of 
funds in the course of the 
transaction. 

(iii) Host Transfer Services. The 
term 'host transfer services' 
means any electronic fund 
transfer made by an automated 
teller machine operator in 
connection with a transaction 
initiated by a consumer at an 
automated teller machine 
operated by such operator. 

[15 USC 1693b.] 



SECTION 905- 
Traosfers 



-Terms and Conditions of 



(a) The terms and conditions of electronic fund 
transfers involving a consumer's account shall be 
disclosed at the time the consumer contracts for an 
electronic fund transfer service, in accordance with 
regulations of the Board. Such disclosures shall be 
in readily understandable language and shall 
include, to the extent applicable— 

(1) the consumer's liability for unauthorized 
electronic fund transfers and, at the financial 
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institution's option, notice of the advisability 
of prompt reporting of any loss, theft, or 
unauthorized use of a card, code, or other 
means of access; 

(2) the telephone number and address of the 
person or office to be notified in the event 
the consumer believes that an unauthorized 
electronic fund transfer has been or may be 
effected; 

(3) the type and nature of electronic fund 
transfers which the consumer may initiate, 
including any limitations on the frequency or 
dollar amount of such transfers, except that 
the details of such limitations need not be 
disclosed if their confidentiality is necessary 
to maintain the security of an electronic fund 
transfer system, as determined by the Board; 



(4) 



(5) 



(6) 



(7) 



any charges for electronic fund transfers or 
for the right to make such transfers; 



the consumer's right to stop payment of a 
preauthorized electronic fund transfer and 
the procedure to initiate such a stop payment 
order; 

the consumer's right to receive documenta- 
tion of electronic fund transfers under 
section 906; 

a summary, in a form prescribed by 
regulations of the Board, of the error 
resolution provisions of section 908 and the 
consumer's rights thereunder. The financial 
institution shall thereafter transmit such 
summary at least once per calendar year; 



(8) the financial institution's liability to the 
consumer under section 910; 

(9) under what circumstances the financial 
institution will in the ordinary course of 
business disclose information concerning the 
consumer's account to third persons; and 

(10) a notice to the consumer that a fee may be 
imposed by 

(A) an automated teller machine operator 
(as defined in section 904(d)(3)(D)(i)) 
if the consumer initiates a transfer from 
an automated teller machine that is not 
operated by the person issuing the card 
or other means of access; and 

(B.) any national, regional, or local network 
utilized to effect the transaction. 



(b) A financial institution shall notify a consumer in 
writing at least twenty-one days prior to the 
effective date of any change in any term or condi- 
tion of the consumer's account required to be 
disclosed under subsection (a) if such change would 
result in greater cost or liability for such consumer 
or decreased access to the consumer's account. A 
financial institution may, however, implement a 
change in the terms or conditions of an account 
without prior notice when such change is 
immediately necessary to maintain or restore the 
security of an electronic fund transfer system or a 
consumer's account. Subject to subsection (a)(3), 
the Board shall require subsequent notification if 
such a change is made permanent. 

(c) For any account of a consumer made accessible to 
electronic fund transfers prior to the effective date 
of this title, the information required to be disclosed 
to the consumer under subsection (a) shall be 
disclosed not later than the earlier of— 

(1) the first periodic statement required by 
section 906(c) after the effective date of this 
title; or 

(2) thirty days after the effective date of this 
title. 

[15 USC 1693c] 

SECTION 906— Documentation of 
Transfers; Periodic Statements 

(a) For each electronic fund transfer initiated by a 
consumer from an electronic terminal, the financial 
institution holding such consumer's account shall, 
directly or indirectly, at the time the transfer is 
initiated, make available to the consumer written 
documentation of such transfer. The documentation 
shall clearly set forth to the extent applicable-— 

(1) the amount involved and date the transfer is 
initiated; 

(2) the type of transfer; 

(3) the identity of the consumer's account with 
the financial institution from which or to 
which funds are transferred; 

(4) the identity of any third party to whom or 
from whom funds are transferred; and 

(5) the location or identification of the electronic 
terminal involved. 

(b) For a consumer's account which is scheduled to be 
credited by a preauthorized electronic fund transfer 
from the same payor at least once in each 
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successive sixty-day period, except where the payor 
provides positive notice of the transfer to the 
consumer, the financial institution shall elect to 
provide promptly either positive notice to the 
consumer when the credit is made as scheduled, or 
negative notice to the consumer when the credit is 
not made as scheduled, in accordance with 
regulations of the Board. The means of notice 
elected shall be disclosed to the consumer in 
accordance with section 905. 

(c) A financial institution shall provide each consumer 
with a periodic statement for each account of such 
consumer that may be accessed by means of an 
electronic fund transfer. Except as provided in 
subsections (d) and (e), such statement shall be 
provided at least monthly for each monthly or 
shorter cycle in which an electronic fund transfer 
affecting the account has occurred, or every three 
months, whichever is more frequent. The statement, 
which may include information regarding 
transactions other than electronic fund transfers, 
shall clearly set forth— 

(1) with regard to each electronic fund transfer 
during me period, me information described 
in subsection (a), which may be provided on 
an accompanying document; 

(2) the amount of any fee or charge assessed by 
the financial institution during the period for 
electronic fund transfers or for account 
maintenance; 

(3) the balances in the consumer's account at the 
beginning of the period and at the close of 
the period; and 

(4) the address and telephone number to be used 
by the financial institution for the purpose of 
receiving any statement inquiry or notice of 
account error from the consumer. Such 
address and telephone number shall be 
preceded by the caption "Direct Inquiries 
To:" or other similar language indicating that 
the address and number are to be used for 
such inquiries or notices. 

(d) In the case of a consumer's passbook account which 
may not be accessed by electronic fund transfers 
other than preauthorized electronic fund transfers 
crediting the account, a financial institution may, in 
lieu of complying with the requirements of 
subsection (c), upon presentation of the passbook 
provide the consumer in writing with the amount 
and date of each such transfer involving the account 
since the passbook was last presented. 

(e) In the case of a consumer's account other than a 
passbook account, which may not be accessed by 
electronic fund transfers other than preauthorized 



electronic fund transfers crediting the account, the 
financial institution may provide a periodic 
statement on a quarterly basis which otherwise 
complies with the requirements of subsection (c). 

(f) In any action involving a consumer, any 
documentation required by this section to be given 
to the consumer which indicates that an electronic 
fund transfer was made to another person shall be 
admissible as evidence of such transfer and shall 
constitute prima facie proof that such transfer was 
made. 

[15 USC 1693d.] 
SECTION 907— Preauthorized Transfers 

(a) A preauthorized electronic fund transfer from a 
consumer's account may be authorized by the 
consumer only in writing, and a copy of such 
authorization shall be provided to the consumer 
when made. A consumer may stop payment of a 
preauthorized electronic fund transfer by notifying 
the financial institution orally or in writing at any 
time up to three business days preceding the 
scheduled date of such transfer. The financial 
institution may require written confirmation to be 
provided to it within fourteen days of an oral 
notification if, when the oral notification is made, 
the consumer is advised of such requirement and 
the address to which such confirmation should be 
sent. 

(b) In the case of preauthorized transfers from a 
consumer's account to the same person which may 
vary in amount, the financial institution or 
designated payee shall, prior to each transfer, 
provide reasonable advance notice to the consumer, 
in accordance with regulations of the Board, of the 
amount to be transferred and the scheduled date of 
the transfer. 

■■■;:■■ [15 USC 1693c] 

SECTION 908^Error Resolution 

(a) If a financial institution, within sixty days after 
having transmitted to a consumer documentation 
pursuant to section 906 (a), (c), or (d) or 
notification pursuant to section 906(b), receives 
oral or written notice in which the consumer— - 

(1) sets forth or otherwise enables the financial 
institution to identify the name and account 
number of the consumer; 

(2) indicates the consumer's belief that the 
documentation, or, in the case of notification 
pursuant to section 906(b), the consumer's 
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account, contains an error and the amount of 
such error; and 



(3) sets forth the reasons for the consumer's 
belief (where applicable) that an error has 
occurred, the financial institution shall 
investigate the alleged error, determine 
whether an error has occurred, and report or 
mail the results of such investigation and 
determination to the consumer within ten 
business days. The financial institution may 
require written confirmation to be provided 
to it within ten business days of an oral 
notification of error if, when the oral 
notification is made, the consumer is advised 
of such requirement and the address to which 
such confirmation should be sent. A financial 
institution which requires written confirma- 
tion in accordance with the previous sentence 
need not provisionally recredit a consumer's 
account in accordance with subsection (c), 
nor shall the financial institution be liable 
under subsection (e) if the written 
confirmation is not received within the 
ten-day period referred to in the previous 
sentence. 

(b) If the financial institution determines that an error 
did occur, it shall promptly, but in no event more 
than one business day after such determination, 
correct the error, subject to section 909, including 
the crediting of interest where applicable, 

(c) If a financial institution receives notice of an error 
in the manner and within the time period specified 
in subsection (a), it may, in lieu of the requirements 
of subsections (a) and (b), within ten business days 
after receiving such notice provisionally recredit 
the consumer's account for the amount alleged to be 
in error, subject to section 909, including interest 
where applicable, pending the conclusion of its 
investigation and its determination of whether an 
error has occurred. Such investigation shall be 
concluded not later than forty- five days after receipt 
of notice of the error. During the pendency of the 
investigation, the consumer shall have full use of 
the funds provisionally recredited. 

(d) If the financial institution determines after its 
investigation pursuant to subsection (a) or (c) that 
an error did not occur, it shall deliver or mail to the 
consumer an explanation of its findings within 3 
business days after the conclusion of its 
investigation, and upon request of the consumer 
promptly deliver or mail to the consumer 
reproductions of all documents which the financial 
institution relied on to conclude that such error did 
not occur. The financial institution shall include 
notice of the right to request reproductions with the 
explanation of its findings. 



(e) If in any action under section 915, the court finds 
that— 

(1 ) the financial institution did not provisionally 
recredit a consumer's account within the 
ten-day period specified in subsection (c), 
and the financial institution (A) did not make 
a good faith investigation of the alleged 
error, or (B) did not have a reasonable basis 
for believing that the consumer's account was 
notinerror; or 

(2) the financial institution knowingly and 
willfully concluded that the consumer's 
account was not in error when such 
conclusion could not reasonably have been 
drawn from the evidence available to the 
financial institution at the time of its 
investigation, then the consumer shall be 
entitled to treble damages determined under 
section 915(a)(1). 

(f) For the purpose of this section, an error consists 
■..;■. :; fi_ ;■:■.■■ 

(1) an unauthorized electronic fund transfer; 

(2) an incorrect electronic fund transfer from or 
to the consumer's account; 

(3) the omission from a periodic statement of an 
electronic fund transfer affecting the 
consumer's account which should have been 
included; 

(4) a computational error by the financial 
institution; 

(5) the consumer's receipt of an incorrect amount 
of money from an electronic terminal; 

(6) a consumer's request for additional 
information or clarification concerning an 
electronic fund transfer or any 
documentation required by this title; or 

(7) any other error described in regulations of 
the Board. 

[15USG1693f] 

SECTION 909— Consumer Liability for 
Unauthorized Transfers 

(a) A consumer shall be liable for any unauthorized 
electronic fund transfer involving the account of 
such consumer only if the card or other means of 
access utilized for such transfer was an accepted 
card or other means of access and if the issuer of 
such card, code, or other means of access has 
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provided a means whereby the user of such card, 
code, or other means of access can be identified as 
the person authorized to use it, such as by 
signature, photograph, or fingerprint or by 
electronic or mechanical confirmation. In no event, 
however, shall a consumer's liability for an 
unauthorized transfer exceed the lesser of— 

(1) $50;or 



(2) the amount of money or value of property or 
services obtained in such unauthorized 
electronic fund transfer prior to the time the 
financial institution is notified of, or 
otherwise becomes aware of, circumstances 
which lead to the reasonable belief that an 
unauthorized electronic fund transfer 
involving the consumer's account has been or 
maybe effected. Notice under this paragraph 
is sufficient when such steps have been taken 
as may be reasonably required in the 
ordinary course of business to provide the 
financial institution with the pertinent 
information, whether or not any particular 
officer, employee, or agent of the financial 
institution does in fact receive such informa- 
tion. 

Notwithstanding the foregoing, reimbursement need 
not be made to the consumer for losses the financial 
institution establishes would not have occurred but 
for the failure of the consumer to report within sixty 
days of transmittal of the statement (or in extenu- 
ating circumstances such as extended travel or 
hospitalization, within a reasonable time under the 
circumstances) any unauthorized electronic fund 
transfer or account error which appears on the 
periodic statement provided to the consumer under 
section. 906. In addition, reimbursement need not be 
made to the consumer for losses which the financial 
institution establishes would not have occurred but 
for the failure of the consumer to report any loss or 
theft of a card or other means of access within two 
business days after the consumer learns of the loss 
or theft (or in extenuating circumstances such as 
extended travel or hospitalization, within a longer 
period which is reasonable under the 
circumstances), but the consumer's liability under 
this subsection in any such case may not exceed a 
total of $500, or the amount of unauthorized 
electronic fund transfers which occur following the 
close of two business days (or such longer period) 
after the consumer learns of the loss or theft but 
prior to notice to the financial institution under this 
subsection, whichever is less. 



(b) In any action which involves a consumer's liability 
for an unauthorized electronic fund transfer, the 
burden of proof is upon the financial institution to 
show that the electronic fund transfer was 
authorized or, if the electronic fund transfer was 



unauthorized, then the burden of proof is upon the 
financial institution to establish that the conditions 
of liability set forth in subsection (a) have been 
met, and, if the transfer was initiated after the 
effective date of section 905, that the disclosures 
required to be made to the consumer under section 
905(a) (1) and (2) were in fact made in accordance 
with such section, 

(c) In the event of a transaction which involves both an 
unauthorized electronic fund transfer and an 
extension of credit as defined in section 1 03(e) of 
this Act pursuant to an agreement between the 
consumer and the financial institution to extend 
such credit to the consumer in the event the 
consumer's account is overdrawn, the limitation on 
the consumer's liability for such transaction shall be 
determined solely in accordance with this section. 

(d) Nothing in this section imposes liability upon a 
consumer for an unauthorized electronic fund 
transfer in excess of his liability for such a transfer 
under other applicable law or under any agreement 
with the consumer's financial institution. 

(e) Except as provided in this section, a consumer 
incurs no liability from an unauthorized electronic 
fund transfer. 

[15USC1693g.] 



SECTION 910— Liability of Financial 
Institutions 

(a) Subject to subsections (b) and (c), a financial 
institution shall be liable to a consumer for all 
damages proximately caused by— 



(i) 



the financial institution's failure to make an 
electronic fund transfer, in accordance with 
the terms and conditions of an account, in the 
correct amount or in a timely manner when 
properly instructed to do so by the consumer, 
except where— 

(A) the consumer's account has insufficient 
funds; 

(B) the funds are subject to legal process or 
other encumbrance restricting such 
transfer; 

(C) such transfer would exceed an 
established credit limit; 

(D) an electronic terminal has insufficient 
cash to complete the transaction; or 

(E) as otherwise provided in regulations of 
the Board; 
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(2) 



(b) 



the financial institution's failure to make an 
electronic fund transfer due to insufficient 
funds when the financial institution failed to 
credit, in accordance with the terms and 
conditions of an account, a deposit of funds 
to the consumer's account which would have 
provided sufficient funds to make the 
transfer, and (3) the financial institution's 
failure to stop payment of a preauthorized 
transfer from a consumer's account when 
instructed to do so in accordance with the 
terms and conditions of the account. 



A financial institution shall not be liable under 
subsection (a)(1) or (2) if the financial institution 
shows by a preponderance of the evidence that its 
action or failure to act resulted from— 



( 1) an act of God or other circumstance beyond 
its control, that it exercised reasonable care 
to prevent such an occurrence, and that it 
exercised such diligence as the 
circumstances required; or 

(2) a technical malfunction which was known to 
the consumer at the time he attempted to 
initiate an electronic fund transfer or, in the 
case of a preauthorized transfer, at the time 
such transfer should have occurred. 

(c) In the case of a failure described in subsection (a) 
which was not intentional and which resulted from 
a bona fide error, notwithstanding the maintenance 
of procedures reasonably adapted to avoid any such 
error, the financial institution shall be liable for 
actual damages proved. 

(d) Exception for Damaged Notices. If the notice 
required to be posted pursuant to section 
904(d)(3)(B)(i) by an automated teller machine 
operator has been posted by such operator in 
compliance with such section and the notice is 
subsequently removed, damaged, or altered by any 
person other than the operator of the automated 
teller machine, the operator shall have no liability 
under this section for failure to comply with section 
904(d)(3XB)(i). 

[15USC1693h.] 

SECTION 911— Issuance of Cards or Other 
Means of Access 

(a) No person may issue to a consumer any card, code, 
or other means of access to such consumer's 
account for the purpose of initiating an electronic 
fund transfer other than— 

(1 ) in response to a request or application 
therefor; or 



(2) as a renewal of, or in substitution for, an 
accepted card, code, or other means of 
access, whether issued by the initial issuer or 

a successor. 

(b) Notwithstanding the provisions of subsection (a), a 
person may distribute to a consumer on an 
unsolicited basis a card, code, or other means of 
access for use in initiating an electronic fund 
transfer from such consumer's account, if— 

(1) such card, code, or other means of access is 
not validated; 

(2) such distribution is accompanied by a 
complete disclosure, in accordance with 
section 905 , of the consumer's rights and 
liabilities which will apply if such card, 
code, or other means of access is validated; 

(3) such distribution is accompanied by a clear 
explanation, in accordance with regulations 
of the Board, that such card, code, or other 
means of access is not validated and how the 
consumer may dispose of such code, card, or 
other means of access if validation is not 
desired; and 

(4) such card, code, or other means of access is 
validated only in response to a request or 
application from the consumer, upon 
verification of the consumer's identity. 

(c) For the purpose of subsection (b), a card, code, or 
other means of ace ess is validated when it may be 
used to initiate an electronic fund transfer. 

[15USC1693i.] 



SECTION 912- 
Obligations 



-Suspension of 




If a system malfunction prevents the effectuation of an 
electronic fund transfer initiated by a consumer to another 
person, and such other person has agreed to accept 
payment by such means, the consumer's obligation to the 
other person shall be suspended until the malfunction is 
corrected and the electronic fund transfer may be 
completed, unless such other person has subsequently, by 
written request, demanded payment by means other than 
an electronic fund transfer. 

[15USC1693J.] 
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SECTION 913— Compulsory Use of 
Electronic Fund Transfers 

No person may— 

(1) condition the extension of credit to a consumer on 
such consumer's repayment by means of 
preauthorized electronic ftmd transfers; or 

(2) require a consumer to establish an account for 
receipt of electronic fund transfers with a particular 
financial institution as a condition of employment 
or receipt of a government benefit 

[15 USC 1693k.] 
SECTION 914— Waiver of Rights 

No writing or other agreement between a consumer and 
any other person may contain any provision which 
constitutes a waiver of any right conferred or cause of 
action created by this title. Nothing in this section 
prohibits, however, any writing or other agreement which 
grants to a consumer a more extensive right or remedy or 
greater protection than contained in this title or a waiver 
given in settlement of a dispute or action. 

[15USC1693L] 

SECTION 915— Civil Liability 

(a) Except as otherwise provided by this section and 
section 910, any person who fails to comply with 
any provision of this title with respect to any 
consumer, except for an error resolved in 
accordance with section 908, is liable to such 
consumer in an amount equal to the sum of— 



(1) any actual damage sustained by 
consumer as a result of such failure ; 



such 



(2) (A) in the case of an individual action, an 
amount not less than $ 1 00 nor greater 
than $1,000; or 



(B) 



(3) 



in the case of a class action, such 
amount as the court may allow, except 
that (I) as to each member of the class 
no minimum recovery shall be 
applicable, and (ii) the total recovery 
under this subparagraph in any class 
action or series of class actions arising 
out of the same failure to comply by the 
same person shall not be more than the 
lesser of $500,000 or 1 per centum of 
the net worth of the defendant; and 



in the case of any successful action to 
enforce the foregoing liability, the costs of 



the action, together with a reasonable 
attorney's fee as determined by the court, 

(b) In determining the amount of liability in any action 
under subsection (a), the court shall consider, 
among other relevant factors— 

(1) in any individual action under subsection 
(a)(2)(A), the frequency and persistence of 
noncompliance, the nature of such 
noncompliance, and the extent to which the 
noncompliance was intentional; or 

(2) in any class action under subsection 
(a)(2)(B), the frequency and persistence of 
noncompliance, the nature of such 
compliance, the resources of the defendant, 
the number of persons adversely affected, 
and the extent to which the noncompliance 
wa 

(c) Except as provided in section 910, a person may 
not be held liable in any action brought under this 
section for a violation of this title if the person 
shows by a preponderance of evidence that the 
violation was not intentional and resulted from a 
bona fide error notwithstanding the maintenance of 
procedures reasonably adapted to avoid any such 

'. error. 

(d) No provision of this section or section 9 1 6 
imposing any liability shall apply to— 

(1) any act done or omitted in good faith in 
conformity with any rule, regulation, or 
interpretation thereof by the Board or in 
conformity with any interpretation or 
approval by an official or employee of the 
Federal Reserve System duly authorized by 
the Board to issue such interpretations or 
approvals under such procedures as the 
Board may prescribe therefor; or 

(2) any failure to make disclosure in proper form 
if a financial institution utilized an 
appropriate model clause issued by the 
Board, notwithstanding that after such act, 
omission, or failure has occurred, such rule, 
regulation, approval, or model clause is 
amended, rescinded, or determined by 
judicial or other authority to be invalid for 
any reason. 

(e) A person has no liability under this section for any 
failure to comply with any requirement under this 
title if, prior to the institution of an action under 
this section, the person notifies the consumer 
concerned of the failure, complies with the 
requirements of this title, and makes an appropriate 
adjustment to the consumer's account and pays 
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actual damages or, where applicable, damages in 
accordance with section 910. 

(f) On a finding by the court that an unsuccessful 
action under this section was brought in bad faith or 
for purposes of harassment, the court shall award to 
the defendant attorney's fees reasonable in relation 
to the work expended and costs. 

(g) Without regard to the amount in controversy, any 
action under this section may be brought in any 
United States district court, or in any other court of 
competent jurisdiction, within one year from the 
date of the occurrence of the violation. 

[15 USC 1693m.] 
SECTION 916— Criminal Liability 

(a) Whoever knowingly and willfully— 

(1) gives false or inaccurate information or fails 
to provide information which he is required 
to disclose by this title or any regulation 
issued thereunder; or 

(2) otherwise fails to comply with any provision 
of this title; shall be fined not more than 
$5,000 or imprisoned not more than one 
year, or both. 

(b) Whoever— 

(1) knowingly, in a transaction affecting 
interstate or foreign commerce, uses or 
attempts or conspires to use any counterfeit, 
fictitious, altered, forged, lost, stolen, or 
fraudulently obtained debit instrument to 
obtain money, goods, services, or anything 
else of value which within any one-year 
period has a value aggregating $1,000 or 
more; or 

(2) with unlawful or fraudulent intent, transports 
or attempts or conspires to transport in 
interstate or foreign commerce a counterfeit, 
fictitious, altered, forged, lost, stolen, or 
fraudulently obtained debit instrument 
knowing the same to be counterfeit, ficti- 
tious, altered, forged, lost, stolen, or 
fraudulently obtained; or 

(3) with unlawful or fraudulent intent, uses any 
instrumentality of interstate or foreign 
commerce to sell or transport a counterfeit, 
fictitious, altered, forged, lost, stolen, or 

frau 

owing the same to be counterfeit, fictitious, 
altered, forged, lost, stolen, or fraudulently 
obtained; or 



(4) knowingly receives, conceals, uses, or 
transports money, goods, services, or 
anything else of value (except tickets for 
interstate or foreign transportation) which 
(A) within any one-year period has a value 
aggregating $ 1 ,000 or more, (B) has moved 
in or is part of, or which constitutes interstate 
or foreign commerce and (C) has been 
obtained with a counterfeit, fictitious, 
altered, forged, lost, stolen, or fraudulently 
obtained debit instrument; or 

(5) knowingly receives, conceals, uses, sells, or 
transports in interstate or foreign commerce 
one or more tickets for interstate or foreign 
transportation, which (A) within any 
one-year period have a value aggregating 
$500 or more, and (B) have been purchased 
or obtained with one or more counterfeit, 
fictitious, altered, forged, lost, stolen, or 
fraudulently obtained debit instrument; or 

(6) in a transaction affecting interstate or foreign 
commerce, furnishes money, property, 
services, or anything else of value, which 
within any one-year period has a value 
aggregating $ 1 ,000 or more, through the use 
of any counterfeit, fictitious, altered, forged, 
lost, stolen, or fraudulently obtained debit 
instrument knowing the same to be 
counterfeit, fictitious, altered, forged, lost, 
stolen, or fraudulently obtained shall be fined 
not more than $10,000 or imprisoned not 
more than ten years, or both. 

(c) As used in this section, the term "debit instrument" 
means a card, code, or other device, other than a 
check, draft, or similar paper instrument, by the use 
of which a person may initiate an electronic fund 
transfer. 



[15USC 1693n.] 

-Administrative 




SECTION 917- 

Eeforcemeist 



(a) Compliance with the requirements imposed under 
this title shall be enforce 

.".'.'. (1) section 8 of the Federal Deposit Insurance 
Act, in the case of— - 

(A) national banks, and Federal branches 
arid Federal agencies of foreign banks, 
by the Office of the Comptroller of the 
Currency; 

(B) member banks of the Federal Reserve 
System (other than national banks), 
branches and agencies of foreign banks 
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(other than Federal branches/Federal 
agencies, and insured State branches of 
foreign banks), commercial lending 
companies owned or controlled by 
foreign banks, and organizations 
operating under section 25 or 25 A of 
the Federal Reserve Act, by the Board; 
and 

(C) banks insured by the Federal Deposit 
Insurance Corporation (other than 
members of the Federal Reserve 
System) and insured State branches of 
foreign banks, by the Board of 
Directors of the Federal Deposit 
Insurance Corporation; 

(2) section 8 of the Federal Deposit Insurance 
Act;by me Director of the Office of Thrift 
Supervision, in the case of a savings 
association the deposits of which are insured 
by the Federal Deposit Insurance 
Corporation; 

(3) the Federal Credit Union Act, by the 
Administrator of the National Credit Union 
Administration with respect to any Federal 
credit union. 



(4) the Federal Aviation Act of 1958, by the 
Secretary of Transportation, with respect to 
any air carrier or foreign air carrier subject to 
that Act; and 

(5) the Securities Exchange Act of 1934, by the 
Securities and Exchange Commission, with 
respect to any broker or dealer subject to that 

■'■' Act. 

The terms used in paragraph (1) that are not defined 
in this title or otherwise defined in section 3(s) of 
the Federal Deposit Insurance Act (12 U.S.C. 
1813(s)) shall have the meaning given to them in 
section 1(b) of the International Banking Act of 
1978 (12 U.S.C. 3101). 

(b) For the purpose of the exercise by any agency 
referred to in subsection (a) of its powers under any 
Act referred to in that subsection, a violation of any 
requirement imposed under this title shall be 
deemed to be a violation of a requirement imposed 
under that Act. In addition to its powers under any 
provision of law specifically referred to in 
subsection (a), each of the agencies referred to in 
that subsection may exercise, for the purpose of 
enforcing compliance with any requirement 
imposed under this title; any other authority 
conferred on it by law. 

(c) Except to the extent that enforcement of the 
requirements imposed under this title is specifically 



committed to some other Government agency under 
subsection (a), the Federal Trade Commission shall 
enforce such requirements. For the purpose of the 
exercise by the Federal Trade Commission of its 
functions and powers under the Federal Trade 
Commission Act, a violation of any requirement 
imposed under this title shall be deemed a violation 
of a requirement imposed under that Act. All of the 
functions and powers of the Federal Trade 
Commission under the Federal Trade Commission 
Act are available to the Commission to enforce 
compliance by any person subject to the 
jurisdiction of the Commission with the 
requirements imposed under this title, irrespective 
of whether that person is engaged in commerce or 
meets any other jurisdictional tests in the Federal 
Trade Commission Act. 

[15 USC 1693o. As amended by acts of Aug. 9, 1989 
(103 Stat. 440) and Dec. 19, 1991 (105 Stat 2301).] 

SECTION 91 8— Reports to Congress 

(a) Not later than twelve months after the effective date 
of this title and at one-year intervals thereafter, the 
Board shall make reports to the Congress 
concerning the administration of its functions under 
this title, including such recommendations as the 
Board deems necessary or appropriate. In addition, 
each report of the Board shall include its 
assessment of the extent to which compliance with 
this title is being achieved, and a summary of the 
enforcement actions taken under section 9 17 of this 
title. In such report, the Board shall particularly 
address the effects of this title on the costs and 
benefits to financial institutions and consumers, on 
competition, on the introduction of new technology, 
on the operations of financial institutions, and on 
the adequacy of consumer protection. 

(b) In the exercise of its functions under this title, the 
Board may obtain upon request the views of any 
other Federal agency which, in the judgment of the 
Board, exercises regulatory or supervisory 
functions with respect to any class of persons 
subject to this title. 

[15 USC 1693p. As amended by act of Dec. 21, 1982 
(96 Stat. 1825).] 

SECTION 919— Relation to State Laws 

This title does not annul, alter, or affect the laws of any 
State relating to electronic fund transfers, except to the 
extent that those laws are inconsistent with the provisions 
of this title, and then only to the extent of the 
inconsistency. A State law is not inconsistent with this 
title if the protection such law affords any consumer is 
greater than the protection afforded by this title. The 
Board shall, upon its own motion or upon the request of 
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any financial institution, State, or other interested party, 
submitted in accordance with procedures prescribed in 
regulations of the Board, determine whether a State 
requirement is inconsistent or affords greater protection. 
If the Board determines that a State requirement is 
inconsistent, financial institutions shall incur no liability 
under the law of that State for a good faith failure to 
comply with that law, notwithstanding that such 
determination is subsequently amended, rescinded, or 
determined by judicial or other authority to be invalid for 
any reason. This title does not extend the applicability of 
any such law to any class of persons or transactions to 
which it would not otherwise apply. 

SECTION 920— Exemption for State 
Regulation 

The Board shall by regulation exempt from the 
requirements of this title any class of electronic fund 
transfers within any State if the Board determines that 
under the law of that State that class of electronic fund 
transfers is subject to requirements substantially similar to 
those imposed by this title, and that there is adequate 
provision for enforcement. 

[15USC1693r.] 
SECTION 921— Effective Date 

This title takes effect upon the expiration of eighteen 
months from the date of its' enactment, except that sections 
909and91 1 take effect upon the expiration of ninety days 
after the date of enactment. 

[15 USC 1693 note.] 
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FEDERAL TAX DEPOSIT PAYMENTS 
Information on the Electronic Federal Tax Payment System 

This section provides important information for corporations required or volunteering to pay federal taxes electronically 
and for financial institutions assisting their corporate customers in meeting their electronic tax obligations. The materials 
contained within this section focus on the Electronic Federal Tax Payment System (EFTPS), under which corporate 
taxpayers are required to pay their Federal tax obligations electronically. The following documents are included: 

• ' ■ Internal Revenue Serviced final regulations for "Electronic Funds Transfers of Federal Deposits" (26 C.F.R. 

Parts 1,20, 25, 31, and 40). 

• . . ■ ■ Internal Revenue Service's Revenue Procedure 97-33. 

• Internal Revenue Service's Revenue Rule 94-46 and 95-68 governing "Failure to Make Deposit of Taxes" and 
"Penalty for Underpayment of Deposits." 

Department of the Treasury's Final Rule concerning Title 3 1 of the Code of Federal Regulation, Part 203, 
"Treasury Payment of Federal Taxes and the Treasury Tax and Loan Program." 

• Electronic Federal Tax Payment System: Risk Issues for Financial Institutions. 

• ' Department of Treasury's Electronic Federal Tax Payment System Highlights. 

• ■' . Tax Payment (TXP) Banking Convention. 
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Federal Register: July 13, 1999 
Volume 64, Number 133 
[Rules and Regulations] 

[Page 37675-37677] 

DEPARTMENT OF THE 
TREASURY 

Internal Revenue Service 

26 CFR Parts 1, 20, 25, 31, and 40 

[TD 8828] 
RIN 1545-AW41 

Electronic Funds Transfers of Federal Deposits 

AGENCY: Internal Revenue Service (IRS), Treasury. 
ACTION: Final regulations. 



SUMMARY: This document contains final regulations 
relating to the deposit of Federal taxes by electronic funds 
transfer (EFT). The final regulations affect certain 
taxpayers required to make deposits of Federal taxes. For 
calendar years beginning after 1999, the final regulations 
provide rules under which certain taxpayers must make 
deposits by EFT. 

DATES: Effective Date: These regulations are effective 
July 13, 1999. Applicability Date: For dates of 
applicabihty, see Sec. 3 1.6302- 1(h)(2). 

FOR FURTHER INFORMATION CONTACT: Vincent 
Surabian, (202) 622-4940 (not 
a toll-free number). 

■ SUPPLEMENTARY INFORMATION: .'■..■'.': 

Background 

This document contains amendments to the Income 
Tax Regulations (26 CFR part 1), the Estate Tax 
Regulations (26 CFR part 20), the Gift Tax Regulations 
(26 CFR part 25), the Employment Taxes and Collection 
of Income Tax at Source Regulations (26 CFR part 31), 
and the Excise Tax Procedural Regulations (26 CFR part 
40). On March 23, 1999, a notice of proposed rulemaking 
was published in the Federal Register (64 FR 13940). A 
public hearing originally scheduled in the notice of 
proposed rulemaking for May 1 1 , 1 999, was canceled as 
there were no requests to speak. Three written comments 
were received. After consideration of all comments, the 
proposed regulations are adopted by this Treasury 
decision. 



Explanation of Provisions 

Section 6302(h) requires that, beginning in fiscal 
year 1 999, 94 percent of employment taxes and 94 percent 
of other depository taxes be collected by EFT. The IRS 
and Treasury Department previously concluded that the 
deposit threshold had to be set at $50,000 to satisfy this 
statutory requirement. More recent experience suggests, 
however, that the statutory requirement can be satisfied 
even if the threshold is set at a substantially higher level. 
Moreover, an increase in the threshold would allow small 
businesses to make the transition to the EFT system at 
their own pace as they adopt electronic funds transfer in 
their other business operations. Accordingly, the final 
regulations increase the deposit threshold to $200,000 in 
aggregate Federal tax deposits during a calendar year. 

The new $200,000 aggregate deposits threshold 
will be applied initially to 1998 deposits, and taxpayers 
that exceed the threshold in 1998 will be required to 
deposit by EFT beginning in 2000. Taxpayers that first 
exceed the threshold in 1999 or a subsequent year will 
similarly be required to deposit by EFT beginning in the 
second succeeding calendar year. A taxpayer that exceeds 
the threshold will not be permitted to resume making 
paper coupon deposits if its deposits fall below $200,000 
in a subsequent year. Although a similar rule applies 
under the current regulations, taxpayers that are currently 
required to deposit by EFT will be given a fresh start and 
will not be required to use EFT unless they exceed the 
$200,000 threshold in 1998 or a subsequent calendar year. 

The final regulations also expand the types of 
nondepository tax payments for which voluntary payment 
by EFT is allowed to include nondepository payments of 
Federal income, estate and gift, employment, and various 
specified excise taxes. 

Public Comments 

Two commentators on the proposed regulations 
opposed the increase in the threshold to $200,000. They 
were concerned that financial institutions and the Federal 
government would have to continue to process large 
volumes of checks and paper coupons. 

In addition, they stated that the increase in 
threshold does not seem justified since the requirement to 
deposit by EFT does not require an investment by the 
taxpayer in new technology and greater use of EFT 
payment methods will contribute to the maintenance of a 
secure and efficient payment system. The two 
commentators conclude that the Federal government 
should continue to use penalty waivers until taxpayers 
become adept at using the system of depositing by EFT 
efficiently and accurately. The two commentators did, 
however, agree with the use of an aggregate deposits test 
to determine whether a taxpayer is required to deposit by 
EFT. 
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As stated in the notice of proposed rulemaking, the 
IRS and Treasury Department are confident that most 
taxpayers currently required to deposit by EFT have come 
to appreciate the simplicity and convenience of the EFT 
system and will continue to deposit by EFT on a voluntary 
basis. Despite the increase in the threshold, the continued 
participation of these taxpayers, coupled with continuing 
efforts to encourage voluntary enrollment, should ensure 
the Congressionally-mandated 94 percent of collections 
by EFT. A lower threshold would, as the commentators 
suggest, result in even greater use of the EFT system. The 
IRS and Treasury Department have concluded, however, 
that the $200,000 threshold appropriately balances 
concerns relating to small businesses against the benefit of 
reduced paper transactions. 

A third comment suggested removal of the rule in 
31 CFR part 203 prohibiting banks from charging fees for 
processing paper coupon deposits. The regulations in 31 
CFR part 203 are issued by the Financial Management 
Service (FMS) of the Treasury Department, rather than by 
the Internal Revenue Service. FMS has received similar 
comments and announced, in the preamble of the 1 99 8 
regulations revising 31 CFR part 203 (63 FR 5643), that 
it intends to issue a notice of proposed rulemaking on 
removing this prohibition. 

Special Analyses 

It has been determined that this Treasury decision 
is not a significant regulatory action as defined in EO 
12866. Therefore, a regulatory assessment is not required. 
It also has been determined that section 553(b) of the 
Administrative Procedure Act (5 U.S.C. chapter 5) does 
not apply to these regulations and, because these 
regulations do not impose a collection of information 
requirement on small entities, the Regulatory Flexibility 
Act (5 U.S.C. chapter 6) does not apply. Pursuant to 
section 7805(f) of the Internal Revenue Code, the notice 
of proposed rulemaking that preceded these regulations 
was submitted to the Chief Counsel for Advocacy of the 
Small Business Administration for comment on its impact 
on small business. Drafting Information: The principal 
author of these regulations is Vincent Surabian, Office of 
Assistant Chief Counsel (Income Tax & Accounting). 
However, other personnel from the IRS and Treasury 
Department participated in their development. 

List of Subjects 

26CFRPartl 

Income taxes, Reporting and record keeping 
requirements. 

26CFRPart20 

Estate taxes, Reporting and record keeping 
requirements. 



26CFRPart25 

Gift taxes, Reporting and record keeping 
requirements. 

26CFRPart31 

Employment taxes, Income taxes, Penalties, 
Pensions, Railroad retirement, Reporting and record 
keeping requirements, Social security, Unemployment 
compensation. 

26CFRPart40 

Excise taxes, Reporting and record keeping 
requirements. 

Adoption of Amendments to the Regulations 

Accordingly, 26 CFR parts 1, 20, 25, 31, and 40 
are amended as follows: 

PART 1--INCOME TAXES 

Paragraph IVThe authority citation for part 1 is 
amended by revising the entry for Sec. 1 .6302-4 to read in 
part as follows: 



Authority: 26 U.S.C. 7805 






Section 1 .6302-4 also issued under 26 U.S.C. 
6302(a), (c), and (h). ** * 

Par. 2, Section 1.6302-4 is revised to read as 
follows: 

Sec. 1.6302-4 Use of financial institutions in 
connection with income taxes; voluntary payments by 
electronic funds transfer. 

Any person may voluntarily remit by electronic 
funds transfer any payment of tax imposed by subtitle A 
of the Internal Revenue Code, including any payment of 
estimated tax. Such payment must be made in accordance 
with procedures prescribed by the Commissioner. 

PART 20-ESTATE TAX; ESTATES OF 
DECEDENTS DYING AFTER AUGUST 16, 1954 

Par. 3. The authority citation for part 20 is 
amended by adding an entry in numerical order to read in 
part as follows: 



Authority: 26 U.S.C. 7805 



* * * 



Section 20.6302-1 also issued under 26 U.S.C. 
6302(a) and (h). * > * 
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Par. 4. Section 20.6302-1 is added to read as 
follows: 

Sec. 20.6302-1 Voluntary payments of estate taxes by 
electronic funds transfer; 

Any person may voluntarily remit by electronic 
funds transfer any payment of tax to which this part 20 
applies. Such payment must be made in accordance with 
procedures prescribed by the Commissioner, 

PART 25--GIFT TAX; GIFTS MADE AFTER 
DECEMBER 31,' 1954 

Pan 5. The authority citation for part 25 is 
amended by adding an entry in numerical order to read in 
part as follows: 

Authority: 26 U.S.C. 7805 *** 

Section 25.6302-1 also issued under 26 U.S.C. 
6302(a) and (h). ** * 

Par. 6. Section 25.6302-1 is added to read as 
follows: 

Sec. 25.6302-1 Voluntary payments of gift taxes by 
electronic funds transfer. 

Any person may voluntarily remit by electronic 
funds transfer any payment of tax to which this part 25 
applies. Such payment must be made in accordance with 
procedures prescribed by the Commissioner. 

PART 31-EMPLOYMENT TAXES AND 
COLLECTION OF INCOME TAX AT SOURCE 

Par. 7. The authority citation for part 31 continues 
to read in part as follows: 

Authority: 26 U.S.C. 7805 * * * 

Par. 8. Section 3 1 .6302-1 is amended as follows: 

1. The heading for paragraph (h)(2) is revised. 

2. A heading is added for paragraph (h)(2)(i). 

3. New paragraph (h)(2)(i)(C) is added. 

4. Paragraph (h)(2)(h) is revised 

5. Paragraph (h)(2)(iii) is added. 

6. Paragraph (m) is redesignated as paragraph (n). 

7. Paragraph (k) is redesignated as new paragraph (m). 

8. Paragraph (j) is redesignated as new paragraph (k). 

9. New paragraph (j) is added. 

The additions and revisions read as follows: 

Sec. 31.6302-1 Federal tax deposit rules for withheld 
income taxes and taxes under the Federal Insurance 
Contributions Act (FICA) attributable to payments 
made after December '31, 1992. -v 



(h)>** 

(2) Applicability of ' requirement- (i) Deposits for 
return periods beginning before January 1 , 2000: (A) *.* 



(C) This paragraph (h)(2)(i) applies only to 
deposits required to be made for return periods beginning 
before January 1, 2000. Thus, a taxpayer, including a 
taxpayer that is required under this paragraph (h)(2)(i) to 
make deposits by electronic funds transfer beginning in 
1 999 or an earlier year, is not required to use electronic 
funds transfer to make deposits for return periods 
beginning after December 3 1, 1999, unless deposits by 
electronic funds transfer are required under paragraph 
(h)(2)(H) of this section. 

(ii) Deposits for return periods beginning after 
December 31, 1999. Unless exempted under paragraph 
(h)(5) of this section, a taxpayer that deposits more than 
$200,000 of taxes described in paragraph (h)(3) of this 
section during a calendar year beginning after December 
31 ,1997, must use electronic funds transfer (as defined in 
paragraph (h)(4) of this section) to make all deposits of 
those taxes that are required to be made for return periods 
beginning after December 31 of the following year and 
must continue to deposit by electronic funds transfer in all 
succeeding years. Thus, a taxpayer that exceeds the 
$200,000 deposit threshold during calendar year 1998 is 
required to make deposits for return periods beginning in 
or after calendar year 2000 by electronic funds transfer. 

(in) Voluntary deposits. A taxpayer that is not 
required by this section to use electronic funds transfer to 
make a deposit of taxes described in paragraph (h)(3) of 
this section may voluntarily make the deposit by 
electronic funds transfer, but remains subject to the rules 
of paragraph (i) of this section, pertaining to deposits by 
Federal tax deposit (FTD) coupon, in making deposits 
other than by electronic funds transfer. 



(j) Voluntary payments by electronic funds 
transfer. Any person may voluntarily remit by electronic 
funds transfer any payment of tax imposed by subtitle C 
of the Internal Revenue Code. Such payment must be 
made in accordance with procedures prescribed by the 
Commissioner. 



PART 40--EXCISE TAX PROCEDURAL 
REGULATIONS 

Par. 9. The authority citation for part 40 is 
amended by adding an entry in numerical order to read in 
part as follows: 




Authority: 26 U.S.C. 7805 * * * 



Section 40.6302(a)- 1 also issued under 26 U.S.C. 
6302 (a) and (h). 
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Par. 10. Section 40.6302(a)-! is added to read as SECTION 2. BACKGROUND 



follows: 

Sec. 40.6302(a)-l Voluntary payments of excise taxes 
by electronic funds transfer. 

Any person may voluntarily remit by electronic 
funds transfer any payment of tax to which this part 40 
applies. Such payment must be made in accordance with 
procedures prescribed by the Commissioner. 

Charles O. Rossotti, 
Commissioner of Internal Revenue. 

Approved: July 2, 1999. 
Donald C. Lubick, 
Assistant Secretary of the Treasury. 
[FR Doc. 99-17517 Filed 7-12-99; 8:45 am] 
BILLING CODE 4830-0 1-U 
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SECTION L PURPOSE 

This revenue procedure provides taxpayers with 
information about the Electronic Federal Tax Payment 
System (EFTPS). EFTPS is an electronic remittance 
processing system for making federal tax deposits (FTDs) 
and federal tax payments (FTPs). EFTPS is the successor 
electronic funds transfer (EFT) system to TAXLINK 
described in Rev. Proc. 94-48, 1994-2 CB. 694. 



.01 Section 6302(c) of the Internal Revenue Code 
provides that the Secretary of the Treasury (Secretary) 
may authorize Federal Reserve banks, and incorporated 
banks and other financial institutions that are depositories 
or financial agents of the United States, to receive any tax 
imposed under the internal revenue laws, in such manner, 
at such times, and under such conditions as the Secretary 
may prescribe. Section 6302(c) also provides that the 
Secretary shall prescribe the manner, times, and 
conditions under which the receipt of such tax by such 
banks and other financial institutions is to.be treated as a 
payment of such tax to the Secretary. 

.02 Section 6302(h) requires the Secretary to 
establish an EFT system to collect the FTDs of certain 
taxpayers. TAXLINK and its successor, EFTPS, are the 
EFT systems developed by the Secretary to collect federal 
taxes. The TAXLINK system will terminate on July 15, 
1997. All taxpayers making FTDs or FTPs by EFT must 
use EFTPS after July 15, 1997. 



.03 Some taxpayers are required by regulations 
issued under § 6302(h) to make FTDs using an EFT 
system. See § 3 1.6302- 1 (h)(2)(i)(A) of the Employment 
Taxes and Collection of Income Tax at Source 
Regulations. Taxpayers not required to make FTDs using 
an EFT system may choose to do so voluntarily. 
Taxpayers also may choose to make FTPs using EFTPS. 

.04 All taxpayers participating in EFTPS must 
comply with this revenue procedure. 

.05 The two primary payment options in EFTPS 
are an Automated Clearing House (ACH) debit entry and 
an ACH credit entry. Taxpayers may also use the 
Electronic Tax Application (ETA) to accommodate their 
business requirements and meet their FTD and FTP 
obligations. These payment options are described in 
sections 7, 8, and 9 of this revenue procedure. 

.06 Taxpayers participating in EFTPS must ensure 
that their funds are remitted on a timely basis. See § 
31.6302-l(h)(8) for rules regarding when an FTD 
permitted by EFT is deemed made. In the case of FTPs 
remitted by EFT, see § 31.6302-l-(h)(9) for rules 
regarding when the tax is deemed paid. 

.07 A taxpayer required by regulations to make an 
FTD by EFT may not use Form 8109, Federal Tax 
Deposit Coupon, to make an FTD. If the taxpayer is 
unable to make a timely FTD using an ACH debit entry or 
an ACH credit entry, the taxpayer may use ETA to make 
a timely FTD. If a taxpayer is a voluntary participant in 
EFTPS (i.e., a participant not required by regulations to 
make an FTD by EFT) and is unable, for any reason, to 
make an FTD using EFTPS or chooses not to use EFTPS 
to make an FTD, the taxpayer may make a timely FTD by 
using Form 8 109. 
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.08 If an FTD is late, the taxpayer is subject to the 
penalty for failure to timely deposit unless the taxpayer 
establishes reasonable cause for that failure. See Rev. 
Rul. 94-46, 1994-2 C.B. 278. 

.09 EFTPS does not change the computation of tax 
liability, interest or penalties, or FTD or FTP due dates. 

SECTION 3. DEFINITIONS 

.01 The definitions provided in this section will be 
used for EFTPS. 

.02 AUTOMATED CLEARING HOUSE (ACH). 

"Automated Clearing House" is a funds transfer system, 
governed by the ACH Rules (the Operating Rules and the 
Operating Guidelines published by National Automated 
Clearing House Association (NACHA)), that provides for 
the interbank clearing of electronic entries for 
participating financial institutions. 

.03 ACH CREDIT ENTRY. An "ACH credit 
entry" is a transaction in which a financial institution, 
upon instructions from a taxpayer, originates an FTD or 
FTP to the appropriate Department of the Treasury 
(Treasury) account through the ACH system. See section 
8 of this revenue procedure for a description of an ACH 
credit entry. 

.04 ACH DEBIT ENTRY. An "ACH debit entry" 
is a transaction in which one of the Treasury Financial 
Agents, upon instructions from a taxpayer, instructs the 
taxpayer 's financial institution to withdraw fundsfromthe 
taxpayer's account for an FTD or FTP and to route the 
FTD or FTP to the appropriate Treasury account through 
the ACH system. See section 7 of this revenue procedure 
for a description of an ACH debit entry. 

.05 CASH CONCENTRATION OR 
DISBURSEMENT+ TAX PAYMENT ADDENDA 
RECORD (CCD+TXP). The "CCD+ TXP" isNACHA's 
tax payment convention that will be used to facilitate the 
transmission of me tax payment information associated 
wim an ACH credit entry to the appropriate Financial 
Agent. This convention consists of the CCD+ electronic 
funds transfer transaction and an addenda record for tax 
payments identified by the three characters, "TXP". The 
ACH, TXP addenda record includes the Taxpayer 
IdentificationNumber (TIN) (i.e., Employer Identification 
Number (EIN), IRS Individual Taxpayer Identification 
Number (ITIN), or Social Security Number (SSN)), the 
tax type code, the tax period end date, and the FTD or 
FTP amount. 

.06 ELECTRONIC FUNDS TRANSFER (EFT). 
An "EFT" is any transfer of funds, other than a transaction 
originated by check, draft, or similar paper instrument, 
which is initiated through an electronic terminal, 
telephonic instrument, computer, or magnetic tape so asto 
order, instruct, or authorize a financial institution or other 
financial intermediary to debit or credit an account. 



.07 ELECTRONIC TAX APPLICATION (ETA). 

"ETA" (also referred to as "Same Day Payment") is a 
subsystem of EFTPS that receives, processes, and 
transmits an FTD or an FTP and the related tax payment 
information for taxpayers that make same day payments 
through Fedwire value transfers, Fedwire non- value 
transactions, and Direct Access transactions. See section 
9 of this revenue procedure for information on the ETA 
process. For more information about ETA payments, 
taxpayers should contact their financial institutions. 

.08 EMPLOYER IDENTIFICATION NUMBER 

(EIN). An "EIN" is a unique nine digit taxpayer 
identifying number issued by the Internal Revenue Service 
to business taxpayers for the purpose of reporting tax 
related information. 

.09 FEDERAL RESERVE BANK (FRB). The 
"FRB" is the U.S. Government's fiscal agent. The FRB 
also processes ACH transactions to a commercial 
financial institution account or to a Treasury account. 

10 FRB HEAD OFFICE LOCAL ZONE TIME. 
"FRB Head Office Local Zone Time" is the local zone 
time of the FRB head office through which a financial 
institution, or its authorized correspondent bank, sends a 
same-day payment. 

.1 1 FINANCIAL AGENT. For purposes of 
EFTPS, a "Financial Agenf (also referred to as a 
"Treasury Financial Agent") is a financial institution that 
is designated as an agent of Treasury. The Secretary has 
designated NationsBank [now Bank of America] and First 
National Bank of Chicago (First Chicago) [now Bank 
One] to be the Financial Agents for EFTPS. A Financial 
Agent processes EFTPS enrollments, receives FTD and 
FTP information, originates ACH debit entries upon 
instructions from taxpayers, and provides customer 
service assistance for EFTPS enrollment and payment 
information. 

.12 IRS INDIVIDUAL TAXPAYER 
IDENTIFICATION NUMBER (ITIN). An "ITIN" is a 

taxpayer identifying number issued by the Service to an 
client individual who is ineligible to receive an SSN for 
the purpose of reporting tax related information. 

.13 PRENOTIFICATION ACH CREDIT. 
"Prenotification ACH credit" is a process whereby a 
taxpayer's financial institution originates a zero dollars 
entry to the appropriate Treasury Routing Transit Number 
(RTN) to verify me Treasury RTN, the Treasury's 
account number, and the taxpayer's TIN. See section 8.02 
of this revenue procedure: 

.14 PRENOTIFICATION ACH DEBIT. 
"Prenotification ACH debit" is a process whereby the 
appropriate Financial Agent originates a zero dollar entry 
to the taxpayer' s financial institution to verify the RTN of 
the taxpayer's financial institution, the taxpayer's account 
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number, and the account type, 
revenue procedure. 



See section 4.03 of this 



. 1 5 TAXPAYER IDENTIFICATION NUMBER 
(TIN). A "TIN" is a taxpayer identifying number 
assigned to a taxpayer for the purpose of reporting tax 
related information. A TIN includes an EIN, ITIN, or 

SSN. 

SECTION 4. ENROLLMENT ; 

This Section has been deleted 

SECTION 5. ASSIGNMENT TO A FINANCIAL 

agent;.;. : 

This Section has been deleted 

SECTION 6. TIMELY INITIATION OF FTD OR 
FTP. . .. 




.0 1 A taxpayer must ensure that the FTD or FTP is 
timely made. Publication 509, Tax Calendars, lists the 
due dates for FTDs and FTPs. 

.02 A taxpayer choosing the ACH debit entry 
payment option may access the EFTPS Voice Response 
System 24 hours a day, seven days a week, or use the PC 
Tax Payment software application. However, the 
taxpayer must initiate its ACH debit entry payment before 
8:00 p.m. Eastern Time of the last business day prior to 
the FTD or FTP due date, 

.03 A taxpayer choosing the ACH credit entry 
payment option must determine whether its financial 
institution offers the ACH credit entry payment option and 
when the taxpayer must initiate an ACH credit entry that 
will settle on or before the FTD or FTP due date. 

SECTION 7. ACH DEBIT ENTRY 

.01 To initiate a timely ACH debit entry, a 
taxpayer must contact the Financial Agent by 8:00 p.m. 
Eastern time of the last business day prior to the FTD or 
FTP due date. A business taxpayer may arrange an ACH 
debit entry up to 30 calendar days in advance of the due 
date. An individual taxpayer may arrange an ACH debit 
entry up to 1 05 calendar days in advance of the due date, 

.02 In order to initiate an ACH debit entry, a 
taxpayer must furnish the Financial Agent with the 
taxpayer's TIN and PIN. The service does not have 
access to the taxpayer's PIN and, therefore, cannot initiate 
an ACH debit entry from the taxpayer's account. 

.03 After a taxpayer initiates an ACH debit entry, 
the Financial Agent will validate the payment information 
and issue an acknowledgment number to the taxpayer. 
The acknowledgment number verifies when the necessary 
payment information was received by a Financial Agent 



but does not constitute proof of payment. See section 10 
of this revenue procedure regarding proof of payment. 

.04 Pursuant to the taxpayer's instructions, the 
Financial Agent, on the date designated by the taxpayer, 
will ■. instruct the taxpayer' s financial institution to 
originate the transfer of funds from the taxpayer's account 
to the appropriate Treasury account. The financial agent 
also will transmit the related payment data, supplied by 
the taxpayer, to the Service for posting to the taxpayer's 
account(s). 

.05 The Service will deem an ACH debit entry 
to have been made at the time of the debit (i.e., when the 
amount is withdrawn from the taxpayer's account and not 
returned or reversed). 



.06 When a timely ACH debit entry cannot be 
made, a taxpayer rmy mstruct the Finan^ 
complete the transaction at the next opportunity to submit 
an ACH debit entry. The taxpayer may also use the ACH 
credit entry payment option or ETA. See section 8 of this 
revenue procedure regarding the use of an ACH credit 
entry and section 9 regarding the use of ETA. A taxpayer 
that is note required to use EFT for FTDs may use the 
paper FTD coupon system. To avoid penalties, the FTD 
or FTP must be received by an appropriate means on or 
before the FTD or FTP due date. 

.07 The ACH Rules will govern ACH debit entry 
returns and reversals. 

SECTION 8. ACH CREDIT ENTRY .';■',: ■ 

,01 If a taxpayer chooses the ACH credit entry 
payment option to make an FTD or FTP, the taxpayer may 
use any financial institution capable of originating an 
ACH credit entry. 

.02 For each TIN used by a taxpayer in making an 
FTD or FTP by an ACH credit entry, the taxpayer should 
request that its financial institution originate a 
prenotification ACH credit. See section 3.13 of this 
revenue procedure. The taxpayer's financial institution 
should not originate an ACH credit entry until the 
financial institution has successrully completed the 
prenotification process. A prenotification ACH credit will 
verify the taxpayer information in the TXP addenda 
record, thereby minimizing the possibility that an ACH 
credit entry will be rejected. 

.03 If the prenotification ACH credit is rejected, 
the financial institution should not originate an ACH 
credit entry for the taxpayer until the financial institution 
has successfully completed the prenotification process. 

.04 To initiate a timely ACH credit entry, a 
taxpayer must take into account its financial institution's 
deadline for originating an ACH credit entry. 
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.05 If the taxpayer timely and accurately requests 
an ACH credit entry, the taxpayer 's financial institution is 
responsible for the timely origination of the ACH credit 
entry with the appropriate Treasury account number and 
the correct format. 

.06 When a timely ACH credit entry cannot be 
made, a taxpayer may instruct the financial institution to 
complete the transaction at the next opportunity to submit 
an ACH credit entry to use ETA. The taxpayer may also 
initiate an ACH debit entry if enrolled for that payment 
option. See section 7 of this revenue procedure regarding 
the use of an ACH debit entry and section 9 regarding the 
use of ETA. A taxpayer that is note required to use EFT 
for FTDs may use the paper FTD coupon system. To 
avoid penalties, the FTD or FTP must be received by an 
appropriate means on or before the FTD or FTP due date. 

.07 The Financial Agent will receive and process 
the ACH credit entry information. The Financial Agent 
will compare the transaction' s remittance detail in the 
CCD+ TXP addenda with .the taxpayer's enrollment 
record data. If they match, the Financial Agent will send 
the FTD or FTP information to the Service for posting to 
the taxpayer's account(s). 

.08 If the Financial Agent cannot identify the 
taxpayer, the ACH credit entry will be returned to the 
originating financial institution. 

.09 Failure to provide correct, complete, and 
properly formatted information may cause an ACH credit 
entry to be returned. In the event of a return, a taxpayer 
may instruct the financial institution to submit a corrected 
ACH credit entry at the next opportunity to use ETA; The 
taxpayer may also initiate an ACH debit entry if enrolled 
for mat payment. Option. A taxpayer that is notrequired 
to use EFT may also use the paper FTD coupon system. 

.10 An ACH credit entry that is not returned 
reversed will be deemed made at the time that the funds 
are paid into the appropriate Treasury account. 

.11 The ACH Rules will govern ACH credit entry 
returns and reversals. 



SECTION 9, 
(ETA) 



ELECTRONIC TAX APPLICATION 



.01 Taxpayers may use ETA (as defined in section 
3.07) to make a timely FTD or FTP. Taxpayers should 
contact their financial institution to determine if the 
financial institution is capable of making and ETA 
payment. 

.02 After The EFTPS enrollment process is 
completed, the Financial Agent will send the taxpayer an 
EFTPS Payment Instruction Booklet that includes 
additional ETA information under the heading "Same Day 
Payments." 



.03 The Service generally will deem an ETA 
payment to have been made on the date the payment is 
received by the FRB. Taxpayers should contact their 
financial institutions to determine their deadline for 
initiating ETA payments for a particular day. ETA 
payments received by the FRB after the deadline set forth 
in the Treasury Financial Manual, Volume IV (IV TFM), 
will be recorded as received the following business day. 
Currently, the deadline in IV T.M. is 2:00 p.m. FRB Head 
Office Local Zone Time . If a payment is not accepted, the 
payment must be re-originated using ETA or any other 
permissible payment method. 

SECTION 10. PROOF OF PAYMENT 

.01 For an ACH debit or credit entry, a statement 
prepared by the taxpayer' s financial institution showing a 
transfer (that is, a decrease to the taxpayer's account 
balance) will be accepted as proof of payment if the 
statement: 



and 



(1) shows the amount and the date of the transfer; 

(2) identifies the U.S. Government as the payee. 



.02 For an ETA payment, taxpayers may request 
that their financial institution obtain a statement from the 
FRB that executed the transfer. This statement will be 
accepted as proof of payment if the state: 



and 



(1) shows the amount and the date of the transfer; 



(2) identifies the U.S. Government as the payee. 



.03 For purposes of this section, statements 
prepared by a financial institution include statements 
prepared by a third party that is contractually obligated to 
prepare statements for the financial institution. 

SECTION 11. REFUNDS 

No refunds of FTDs or FTPs will be made through 
EFTPS. However, a refund request may be made using 
existing tax refund procedures. If a taxpayer's error 
results in a significant hardship, the taxpayer may contact 
the Service at (800) 829-1040 for assistance. 

SECTION 12. ENROLLMENT FORMS AND 
ADDITIONAL INFORMATION ABOUT EFTPS 

This Section has been deleted 

SECTION 13. EFFECT ON OTHER DOCUMENTS 

Rev. Proc. 94-48 is obsoleted for FTDs or FTPs 
made after July 15, 1997. 
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SECTION 14. EFFECTIVE DATE 

This revenue procedure is effective on July 1 1 , 
1997. 

SECTION 15. PAPERWORK REDUCTION ACT 

The collections of information contained in this 
revenue procedure have been reviewed and approved by 
the Office of Management and Budget in accordance with 
the Paperwork Reduction Act (44 U.S. C. 3507) under 
control number 1545-1546. 

An agency may not conduct or sponsor, and a 
person is not required to respond to, a collection of 
information unless the collection of information displays 
a valid control number. 

The collections of information in this revenue 
procedure are in section 10 of this revenue procedure. 
This information is required to implement EFTPS, and 
verify that taxpayers have met their obligations to pay 
their taxes and make FTDs by EFT. This information will 
be used to credit taxpayers ' accounts for FTDs and FTPs 
made through EFTPS. The collections of information in 
section 10 of this revenue procedure is mandatory. The 
likely respondents are individuals, state or local 
governments, farms, business or other for-profit 
institutions, federal agencies or employees, nonprofit 
institutions, and small businesses or organizations. 

In 1999, the estimated total annual reporting and 
record keeping burden will be 690,000 hours. 

The estimated annual burden per respondent and 
record keeper will vary from 15 minutes to 45 minutes, 
depending on individual circumstances, with an estimated 
average of 30 minutes. The estimated number of 
respondents and record keepers 1,380,000. 

The estimated annual frequency of responses is on 
occasion. 

Books or records relating to a collection of 
information must be retained as long as their contents may 
become material in the administration of any internal 
revenue law. Generally tax returns and tax return 
information are confidential, as required by 26 U.S.C 
6103. 



SECTION 6656.--FAILURE TO MAKE 
DEPOSIT OFTAXES;^^^^^^^^^;^^^^^^^^^^^;: ; : 

26 CFR 30L6656-1 : PENALTY FOR 
UNDERPAYMENT OF DEPOSITS. 

. REV^ ^ 

:. issue v : v. : ;.';^ 

How does a taxpayer that makes an electronic 
funds transfer (EFT) establish reasonable cause for 
abating the failure to deposit penalty under §6656 of the 
Internal Revenue Code? 

FACTS,;.. 

A taxpayer may make an EFT either by telephone 
or personal computer using one of two payment options: 
(1) a debit transaction, or (2) a credit transaction. A debit 
transaction is effected by a Financial Agent of the 
Department of the Treasury within the meaning of Rev. 
Proc. 94-48, 1 994-29 LR.B . (dated July 1 8, 1 994). The 
taxpayer requests the Financial Agent to initiate the 
transfer of funds from the taxpayer's bank account(s) to 
Treasury's general account and to transmit the related tax 
payment data, supplied by the taxpayer, to the Internal 
Revenue Service. A credit transaction is effected by the 
taxpayer's financial institution. The taxpayer requests the 
financial institution to initiate the transfer of funds 
through the Automated Clearing House (ACH) system to 
the Treasury's general account and to submit the related 
tax data, supplied by the taxpayer, through the ACH 
system to a Financial Agent for transmission to the 
Service. 

The following situations illustrate various failure- 
to-deposit circumstances. In each situation, the bank 
involved maybe either a Financial Agent initiating a debit 
transaction on behalf of the taxpayer or the taxpayer's 
financial institution initiating a credit transaction through 
the ACH system. 

Situation OV -A had a federal tax deposit due on 
January 5 and was required to make its federal tax 
deposits by EFT. Bank X required that all EFT requests 
be made before 2:00 p.m. eastern time of the banking day 
immediately prior to the banking day the EFT is to be 
completed. On January 4 at 1 :00 p.m. eastern time, A 
contacted Bank X and instructed Bank X to initiate an 
EFT on January 5 (by a debit transaction or a credit 
transaction); causing $30,000 to be withdrawn from A's 
account and transferred to Treasury's general account as 
a first quarter employment tax deposit. Bank X issued an 
acknowledgment number or other certification of the 
request to A at the time A instructed Bank X to make the 
EFT. On January 5, A[s account had sufficient funds to 
cover the $30,000 EFT. 
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On January 6, Bank X initiated the EFT, causing 
$30,000 to be withdrawn fromA's account and transferred 
to Treasury's general account. On May 1 8, A received a 
notice showing a failure to deposit penalty of $600 (2 
percent of the $30,000 liability) for the late deposit made 
on January 6. A requests in writing that the service waive 
the penalty and includes the acknowledgment number or 
other certification of the EFT request. Bank X[s records 
indicate that on January 4 A instructed it to make the EFT 
on January 5. 

Situation (2) . The facts are the same as Situation 
(\\ except Bank X!s records indicate that on January 4 A 
instructed Bank X to initiate the EFT on January 6. As 
books and records do not demonstrate that A instructed 
Bank X to initiate the EFT on January 5. 



LAW AND ANALYSIS 

Section 6656 provides that a penalty shall be 
imposed in case of failure by any person to make a timely 
deposit of tax imposed under the Code unless such failure 
is due to reasonable cause and not to willful neglect. The 
penalty rate is 2 percent of the underpayment if the failure 
to deposit is for not more than 5 days, 5 percent if the 
failure is for more than 5 days but not more than 1 5 days, 
and 10 percent if the failure is for more than 15 days. 

Section 301.6656-l(b) of the Regulations on 
Procedure and Administration provides that a taxpayer 
must make an affirmative showing of all facts alleged as 
a reasonable cause in a written statement containing a 
declaration that the statement is made under penalties of 
perjury. If it is determined that the underpayment was due 
to reasonable cause and not due to willful neglect, the 
penalty will be abated. 

Each reasonable cause request is evaluated on its 
own merits. The merits are determined based on the 
events or parties involved, and whether the taxpayer 
exercised ordinary business care and prudence but was 
unable to meet a tax requirement due to circumstances or 
events beyond the taxpayer's control. 

In Situation (1) , Bank ]Cs records, which the 
Service is able to check based on the acknowledgment 
number or other certification of request provided to the 
Service by the taxpayer, verify that on January 4 at 1 :00 
p.m. eastern time, A instructed Bank X to initiate an EFT 
of $30,000 to Treasury's general account on January 5 for 
a first quarter employment tax deposit. A has reasonable 
cause for the failure to make a timely deposit because A 
timely provided to Bank X the following information: (1) 
payment instructions, (2) the correct amount of tax to be 
deposited, (3) the correct type of tax to be deposited, (4) 
the correct tax period for which the deposit was made, (5) 
the correct date the funds were to be transferred from As 
bank account to Treasury's general account, and (6) the 
number of As bank account with sufficient funds to cover 
the EFT. Therefore, A is not subject to any penalty on the 
EFT of $30,000. The reason Bank X did not transfer the 



funds on January 5 is irrelevant (i.e., disaster, software 
failure, or negligent banking practices) . 

In Situation (2) , Bank X's records indicate that on 
January 4 at 1:00 p.m. eastern time, A instructed Bank X 
to initiate an EFT of $30,000 to Treasury on January 6 for 
a first quarter employment tax deposit. Based on Bank 
X's records, A gave the incorrect date for Bank X to 
initiate the EFT to Treasury's general account. Therefore, 
A does not have reasonable cause for the failure to make 
a timely deposit and is subject to a penalty on the EFT of 
$30,000. In order for A to establish reasonable cause in 
this situation, As contemporaneous books and records 
would need to demonstrate that A instructed Bank X to 
transfer the funds on January 5. Books and records may 
include, among other things, a recording of telephone 
instructions or an electronic file saved at the time the 
instructions were given. 

HOLDING.. ^..^..V 

A taxpayer making an EFT through either a debit 
transaction or a credit transaction may establish 
reasonable cause for abating the failure to deposit penalty 
under § 6656 of the Code by using the records of the bank 
instructed to initiate the EFT (whether a Financial Agent 
or the taxpayer's financial institution), and/or the 
taxpayer's books and records (including, among other 
things, a recording of telephone instructions or a saved 
electronic file of instructions), to establish that the 
taxpayer timely provided to the bank the following 
information: (1) payment instructions, (2) the correct 
amount of tax to be deposited, (3) the correct type of tax 
to be deposited, (4) the correct tax period for which the 
deposit was made, (5) the correct date the funds were to 
be transferred from the taxpayer's bank account to 
Treasury's general account, and (6) the number of the 
taxpayer's bank account with sufficient funds to cover the 

EFX/ ; .- ;. ■ . ; . . . :^ ;;:■:■..:■. . . : ^;\ 

DRAFTING INFORMATION 

The principal author of this revenue ruling is John 
Moran of me Office of Assistant Chief Counsel (income 
Tax and Accounting). For further information regarding 
this revenue procedure, contact John Moran on (202) 622- 
6232 (not a toll-free call). 
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PARTI 

SECTION 6656. -FAILURE TO MAKE 
DEPOSIT OF TAXES 

26 CFR 301.6656-1: PENALTY FOR 
UNDERPAYMENT OF DEPOSITS. (ALSO 
PART I, § 6302; 31.6302-lT.) 



REY. RUL. 95-68 : 
issues. ;y ;; : ; : : 

(1) Is a taxpayer that is required to deposit federal 
taxes by electronic funds transfer (EFT) subject to the 
failure-to-deposit penalty imposed by §6656 of the 
Internal Revenue code if the taxpayer deposits the taxes 
by means other than EFT, or by EFT after the date on 
which the taxes are due? 

(2) Is a taxpayer that is not required to deposit 
taxes by EFT, but has done so on a voluntary basis, 
subj ect to the failure-to-deposit penalty imposed by § 665 6 
if the taxpayer instead timely deposits the taxes at an 
authorized depository? 

FACTS..;.:.. . 

Situation 1 . A was required to make a federal tax 
deposit of $100x by EFT on or before January 5, in 
accordance with §6302(h) and §3 1.6302- IT of the 
Employment Taxes and Collection of Income Tax at 
Source Regulations. Adid not make the $ 1 OOx deposit by 
EFT. Instead, A used a Form 8109, Federal Tax Deposit 
Coupon, to make the $ 1 OOx deposit on January 5 at Bank 
Z, an authorized depository for deposits made with that 
form. 

Situation 2 . The facts are the same as in Situation 
I except that A made the $1 OOx deposit by EFT on 
January 6. 

Situation 3 . B was not required to make deposits 
by EFT but has done so voluntarily in accordance with 
Rev. Proc. 94-48, 1994-2 C.B. 694. B was required to 
make a federal tax deposit of $ 1 OOx on or before January 
5; B did not make the $1 OOx deposit by EFT. Instead, B 
used a Form 8 1 09 to make the $ 1 OOx deposit on January 
5atBankZ. 

LAW AND ANALYSIS 

Section 6656(a) provides that in the case of any 
failure by any person to deposit (as required by the Code 
or by regulations of the Secretary under the Code) on the 
date prescribed therefore any amount of tax imposed by 
the Code in the government depository authorized under 



section 6302(c) to receive such deposit, a penalty is 
imposed on such person equal to the applicable 
percentage of the amount of the underpayment, unless it 
is shown that such failure is due to reasonable cause and 
not due to willful neglect. 

Under §6656(b)( 1)(A), the "applicable 
percentage" is 2 percent of the underpayment if the failure 
to deposit is for not more than 5 days, 5 percent of the 
underpayment if the failure is for more than 5 days but not 
more than 15 days, and 10 percent of the underpayment if 
the failure is for more than 1 5 days. 

Under §6656(b)(l)(B), the applicable percentage 
is 15 percent of the underpayment if the tax is not 
deposited on or before the earlier of (i) the day 10 days 
after the date of the first delinquency notice to the 
taxpayer under §6303, or (ii) the day on which notice and 
demand for immediate payment is given under §6861, 
6862, or 6331(a) (last sentence). 

Section 6656(b)(2) defines the term 
"underpayment" as the excess of the amount of the tax 
required to be deposited over the amount, if any, of the 
tax deposited on or before the date prescribed therefore. 

Section 6302(c) provides that the Secretary may 
authorize Federal Reserve banks, and incorporated banks, 
trust companies, domestic building and loan associations, 
or credit unions which are depositaries or financial agents 
of the United States, to receive any tax imposed under the 
internal revenue laws, in such manner, at such times, and 
under such conditions as the Secretary may prescribe. 

Section 6302(h), as added by the North American 
Free Trade Agreement Implementation Act (NAFTA), 
Pub. L. No. 103-182, §523, 107 Stat 2057 (1993), 
provides that the Secretary shall prescribe such 
regulations as may be necessary for the development and 
implementation of an EFT system for the collection of 
depository taxes. The section provides further that the 
system must be designed in such manner as may be 
necessary to ensure that such taxes are credited to the 
general account of the Treasury on the date on which such 
taxes would otherwise have been required to be deposited 
under the federal tax deposit system. 

Section 31.6302-lT(h)(l) describes those 
taxpayers required to make deposits by means of EFT and 
when they must commence making such deposits. Section 
3 1 .6302-lT(h)(3) defines an EFT as any transfer of 
depository taxes made in accordance with Rev. Proc. 94- 
48, or in accordance with procedures subsequently 
published by the Commissioner. 

Rev. Proc. 94-48 describes TAXLINK, an 
electronic remittance processing system that the Internal 
Revenue Service uses to accept deposits of federal taxes 
by EFT, and informs taxpayers and financial institutions 
that participate in TAXLINK of their obligations to each 
other and to the Service. Rev. Proc. 94-48 has 
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applicability both to taxpayers required to make deposits 
by EFT and to taxpayers who choose to participate 
voluntarily in the EFT program. Section 2.05 of Rev. 
Proc. 94-48 provides that a taxpayer required by 
regulations to use an EFT to make a deposit cannot revert 
to the paper coupon system to make a deposit. However, 
a taxpayer that voluntarily participates in the EFT 
program may revert to the paper coupon system (using 
Form 8109) to make a deposit so long as the deposit and 
the paper coupon are received by an authorized depository 
bank before the close of business on the deposit due date. 

Rev. Proc. 90-58, 1990-2 C.B. 642, describes how 
a deposit will be credited to a taxpayer's account in 
determining whether the failure-to-deposit penalty 
imposed by §6656 will apply. In Example 5 of Rev. Proc. 
90-58, an employer timely hand-delivered a check to the 
local Internal Revenue Service office to satisfy a deposit 
obligation rather than depositing the check in an 
authorized government depository as required by 
regulations under §6302. Rev. Proc. holds that because 
the amount due was not deposited as required by the 
regulations, the §6656 failure-to-deposit penalty will 
apply. 

In Situation 1 , A was required to make a $100x 
federal tax deposit using EFT. Instead of using EFT, 
however,_A made the deposit at Bank Z using a Form 
8109. This, A^ deposit was not made in the manner 
required by §6302 and the underlying regulations. 
Accordingly, absent reasonable cause, A is subject to the 
10 percent failure-to-deposit penalty under 
§6656(b)(l)(A) because A failed for more than 15 days to 
make the $ 1 OOx federal tax deposit in the manner required 
by §6302 and the underlying regulations. However, A is 
not subject to the 15 percent failure-to-deposit penalty 
under §665 6(b)(1)(B) because the $1 OOx is credited to 
A's account as of January 5 and, thus, the Internal 
Revenue Service will not subsequently demand the 
payment of that amount under a provision specified in 
§6656(b)(l)(B). 

In Situation 2 , A properly made the required $ 1 OOx 
deposit by EFT, but the deposit was made one day late. 
Therefore, absent reasonable cause, A is subject to the 2 
percent failure-to-deposit penalty under § 665 6(b)( 1 )(A) 
because AJs deposit was not more than 5 days late. 

In Situation 3 , B is not subject to any failure-to- 
deposit penalty under §6656 because B v s participation in 
the EFT program was on a voluntary basis, and B timely 
made the required $1 OOx deposit at Bank Z, an authorized 
depository, using Form 8109 (which EFT volunteers are 
permitted to do under Rev. Proc. 94-48). 

HOLDINGS 

(1) Absent reasonable cause, a taxpayer that is 
required to deposit federal taxes by EFT is subject to the 
failure-to-deposit penalty imposed by §6656 if the 



taxpayer deposits the taxes by means other than EFT, or 
by EFT after the date on which the taxes are due. 

(2) A taxpayer that is not required to deposit taxes 
by EFT, but has done so on a voluntary basis, is not 
subjectto me failure-to-deposit penalty imposed by §6656 
if the taxpayer instead timely deposits the taxes at an 
authorized depository using Form 8109. 

DRAFTING INFORMATION 

The principal author of this revenue ruling is Vincent 
Surabian of the Office of the Assistant Chief Counsel 
(Income Tax and Accounting). For further information 
regarding this revenue ruling, contact Mr. Surabian on 
(202) 622-4940 (not a toll-free call). 
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PAYMENT OF FEDERAL TAXES 
AND THE TREASURY TAX AND 
LOAN PROGRAM 

DEPARTMENT OF THE TREASURY 
31CFRPart203 



Explanatory Note 

The Code of Federal Regulations ' (CFR) is published 
annually, with the various titles published on a staggered 
basis throughout the year. Title 31 is scheduled to be 
published each July 1st. The annual volume incorporates 
all regulatory actions occurring since July 1 of the 
previous year. 

The Federal Register is published daily. When the 
Treasury makes a regulatory change (e.g., Interim Rule, 
Final Rule, or Proposed Rule) it is published in the 
Federal Register with background information including 
the rationale for the change. These Federal Register 
entries may not include the entire body of the rule as it 
appears in the annual CFR, but are specific to the changes 
introduced since the latest published CFR. 

Although the content of CFR volumes is current, as of the 
date of publication, these volumes do not include the 
background and explanations provided with publication of 
Interim Rules or Final Rules as they appear in the Federal 
Register. Therefore, to review background information 
associated with changes to the CFR over time, go to the 
current CFR and consult the Federal Register citations of 
any amendments, which are located at the end of each 
section of the Rule. Then, to view that background 
information, go to the Web at www, gpoaccess . gov/fr . and 
enter the publication date furnished in the CFR citation. 

Subpart A— General Information 

Sec. ■' .'■.■ 



Subpart ^Electronic Federal Tax Payments 



203.1 
203.2 
203.3 

203.4 

203.5 
203.6 

203.7 

203.8 



Scope. 

Definitions. 

Financial institution eligibility designation as a 

Treasury Tax and Loan depositary. 

Designation of financial institutions as Treasury 

Tax and Loan depositaries. 

Obligations of the depositary. 

Compensation for services. 

Termination of agreement or change of election or 

option. 

Application of part and procedural instructions. 



203.9 Scope of the subpart. 

203.10 Enrollment. 
Electronic payment methods. 
Future-day reporting and payment mechanisms. 
Same-day reporting and payment mechanisms. 
Electronic Federal Tax Payment System interest 
assessments. 

203. 15 Prohibited debits through the Automated 
Clearing House. 
Appeal and dispute resolution. 



203.11 
203.12 
203.13 
203.14 



203.16 



Subpart C— Federal Tax Deposits. 



203 '. 1 7 Scope of the subpart. 

203.18 Tax deposits using 
coupons. 

203.19 Note option. 

203.20 Remittance option. 



Federal Tax Deposit 



Subpart D— Investment Program and Collateral 
Security Requirements for Treasury Tax and Loan 
Depositaries 

203.2 1 Scope of the subpart. 

203.22 Sources of balances. 

203.23 Note balance. 

203.24 Collateral security requirements, 

AUTHORITY: 12 U.S.C. 90, 265-266, 332, 391, 
1452(d), 1464(k), 1767, 1789a, 20 13, 2 122, and 3 102; 26 
U.S.C. 6302; 31 U.S.C. 321, 323 and 3301-3304. 

SOURCE: 63 FR 5650, Feb. 3, 1998, unless otherwise 
noted. 

Subpart A— General Information 

§203.1 Scope. 

The regulations in this part govern the processing of 
Federal tax payments by financial institutions and the 
Federal Reserve Banks(FRB) using electronic payment or 
paper methods; the designation of Treasury Tax and Loan 
(TT&L) depositaries ; and the operation of the Department 
of the Treasury's (Treasury) investment program. 

§ 203.2 Definitions. 

As used in this part: 

(a) Advice of credit means the Treasury form used 
in the Federal Tax Deposit system that is supplied to 
depositaries to summarize and report Federal tax deposits. 
The current form is Treasury Form 2284. Advice of credit 
information also may be delivered electronically. 

(b) \ Automated Clearing House (ACH) credit entry 
means a transaction originated by a financial institution in 
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accordance with applicable ACH formats and applicable 
laws, regulations, and procedural instructions. 

(c) Automated Clearing House (ACH) debit entry 
means a transaction originated by a Treasury Financial 
Agent (TFA), in accordance with applicable ACH formats 
and applicable laws, regulations, and instructions. 

(d) Business day means any day on which the FRB 
of the district is open. 

(e) Direct Access transaction means same-day 
Federal tax payment information transmitted by a 
financial institution directly to the Electronic Tax 
Application at an FRB using the Fedline Taxpayer 
Deposit Application. 

(f) Direct investment means placement of Treasury 
funds with a depositary and a corresponding increase in a 
depositary's note balance. 

(g) Direct investment means placement of Treasury 
funds with a depositary and a corresponding increase in a 
depositary's main note balance. 

(h) Electronic Tax Application (ETA) means a sub- 
system of EFTPS that receives, processes, and transmits 
sameday Federal tax payment information for taxpayers. 
ETA activity is comprised of Fedwire value transfers, 
Fedwire non- value transactions, and Direct Access 
transactions. V 



and payment to a depositary or an FRB. The depositary 
prepares an advice of credit summarizing all FTDs. 

(p) Federal taxes means those Federal taxes or 
other payments specified by the Secretary of the Treasury 
as eligible for payment through the procedures prescribed 
in this part. 

(q) Fedwire means the funds transfer system 
owned and operated by the FRBs. 



(r) Fedwire non-value transaction means the 
same-day Federal tax payment information transmitted by 
a financial institution to an FRB using a Fedwire type 
1090 message to authorize apayment. 

(s) Fedwire value transfer means a Federal tax 
payment made by a financial institution using a Fedwire 
type 1000 message. 

(t) Financial institution means any bank, savings 
bank, savings and loan association, credit union, or similar 
institution. 

(u) Fiscal Agent means the Federal Reserve acting 
as agent for the Treasury. 

(v) Input Message Accountability Data (IMAD) 
means a unique number assigned to each Fedwire 
transaction by the financial institution sending the 
transaction to an FRB. 



(i) Electronic Tax Application (ETA) reference 
number means the unique number assigned to each ETA 
transaction by an FRB. 

(j) Federal funds rate means the Federal funds rate 
published weekly by the Board of Governors of the 
Federal Reserve System. 

(k) Federal R eserve account means an account 
with reserve or clearing balances held by a financial 
institution at an FRB. 

(1) Federal Reserve Bank of the district means the 
FRB that services the geographical area in which the 
financial institution is located, or such other FRB that may 
be designated in an FRB operating circular. 

(m) Federal Tax Deposit (FTD) means a tax 
deposit or payment made using an FTD coupon. 

(n) Federal Tax Deposit coupon (FTD coupon) 
means a paper form supplied to a taxpayer by the 
Treasury for use in the FTD system to accompany 
deposits of Federal taxes. The current paper form is Form 
8109. 

(o) Federal Tax Deposit system (FTD system) 
means the paper-based system through which taxpayers 
remit Federal tax payments by presenting an FTD coupon 



(w) Main note balance means an open-ended 
interest-bearing note balance maintained at the FRB of the 
district. 

(x) Note option means that program available to a 
TT&L depositary under which Treasury invests in 
obligations of the depositary. The amount of such 
investments will be evidenced by interest-bearing note 
balances maintained at the FRB of the district. 

(y) Procedural instructions means the procedures 
contained in the Treasury Financial Manual, Volume IV 
(IV TFM), other Treasury instructions issued through the 
TFAs, and FRB operating circulars issued consistent with 
this part. 

(z) Recognized insurance coverage means the 
insurance provided by the Federal Deposit Insurance 
Corporation, the National Credit Union Administration, 
and by insurance organizations specifically qualified by 
the Secretary. 

(aa) Remittance option means that program 
available to a depositary that processes FTD payments, 
under which the amount of deposits credited by the 
depositary to the TT&L account will be withdrawn by the 
FRB for deposit to the Treasury General Account on the 
day that the FRB receives the advices of credit supporting 
such deposits. 




FTDPI3 



FEDERAL TAX DEPOSIT PAYMENTS 



2005ACHRULES 




(bb) Same-day payment means the following ETA 
payment options: 

(1) Direct Access transaction; 

(2) Fedwire non-value transaction; and 

(3) Fedwire value transfer. 

(cc) Secretary means the Secretary of the Treasury, 
or the Secretary's delegate. 

(dd) Special direct investment means the 
placement of Treasury funds with a depositary and a 
corresponding increase in a depositary's main note 
balance, where the investment specifically is identified as 
a "special direct investment" and may be secured by 
collateral retained in the possession of the depositary 
pursuant to the terms of §203.24(c)(2)(i). 

(ee) Tax due date means the day on which a tax 
payment is due to Treasury, as determined by statute and 
Internal Revenue Service (IRS) regulations. 

(ff) Term investment option means the program 
available to financial institutions that offers the ability to 
borrow excess Treasury operating funds for a 
predetermined period of time. 

(gg) Term note balance means an interest- bearing 
note balance maintained at the FRB of the district for a 
predetermined period of time. 

(hh) Transaction trace number means an 
identifying number assigned by the taxpayer's financial 
institution to each ACH credit transaction. 

(ii) Treasury Financial Agent (TF A) means a 
financial institution designated as an agent of Treasury for 
processing EFTPS enrollments, receiving EFTPS tax 
payment information, and originating ACH debit entries 
on behalf of Treasury as authorized by the taxpayer. 

(jj) Treasury General Account (TGA) means an 
account maintained in the name of the United States 
Treasury at an FRB. 

(kk) Treasury Tax and Loan (TT&L) account 
means the Treasury account maintained by a depositary in 
which funds are credited by the depositary after receiving 
and collateralizing FTDs. 

(11) Treasury Tax and Loan depositary 
(depositary) means a financial institution designated as a 
depositary by the FRB of the district for the purpose of 
maintaining a TT&L account and/or note balance. 

(mm) Treasury Tax and Loan (TT&L) Program 
means the program for collecting Federal taxes and 
investing the Government's excess operating funds. 



(nn) Treasury Tax and Loan (TT&L) rate of 
interest means the interest charged on the main note 
balance. The TT&L rate of interest is the rate prescribed 
by the Secretary taking into consideration prevailing 
market interest rates. The rate and any rate changes will 
be announced through a TT&L Special Notice to 
Depositaries and will be published in the FEDERAL 
REGISTER and on a web site maintained by Treasury's 
Financial Management Service at 
http://www.fms.treas.gov. 

[63 FR 5650, Feb. 3, 1998, as amended at 67 FR 
11575, Mar. 15,2002] 

§ 203,3 Financial institution eligibility for designation 
as a Treasury Tax and Loan depositary. 

(a) To be designated as a TT&L depositary, a 
financial institution shall be insured as a national banking 
association, state bank, savings bank, savings and loan, 
building and loan, homestead association, Federal home 
loan bank, credit union, trust company, or a U.S. branch 
of a foreign banking corporation, the establishment of 
which has been approved by the Comptroller of the 
Currency. 

(b) A financial institution shall possess the 
authority to pledge collateral to secure TT&L account 
balances and/ or a note balance. 



(c) In order to be designated as a TT&L depositary 
for the purposes of processing tax deposits in the FTD 
system, a financial institution shall possess under its 
charter either general or specific authority permitting the 
maintenance of the TT&L account, the balance of which 
is payable on demand without previous notice of intended 
withdrawal. In addition, note option depositaries shall 
possess either general or specific authority permitting the 
maintenance of a note balance. In the case of note option 
depositaries maintaining main note balances, the authority 
shall permit the maintenance of a main note balance which 
is payable on demand without previous notice of intended 
withdrawal. 

[63 FR 5650, Feb. 3, 1998, as amended at 67 FR 
11576, Mar. 15, 2002] 



§ 203.4 Designation of financial institutions 
Treasury Tax and Loan depositaries. 



as 



(a) Parties to the agreement. To be designated as 
a TT&L depositary, a financial institution shall enter into 
a depositary agreement with Treasury's fiscal agent, the 
FRB. By entering into this agreement, the financial 
institution agrees to be bound by this part, and procedural 
instructions issued pursuant to this part. 

(b)(1) Application procedures. An eligible 
financial institution seeking designation as 
a depositary and, thereby, the authority to 
maintain a TT&L account and/or a note 
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(2) 



balance shall file with the FRB, Financial 
Management Service Form 458, 
"Financial Institution Agreement and 
Application for Designation as a TT&L 
Depositary," and Financial Management 
Service Form 459, "Resolution 
Authorizing the Financial Institution 
Agreement and Application for 
Designation as a TT&L Depositary," 
certified by its board of directors. Financial 
Management Service Forms 458 and 459 
are available upon request from the FRB of 
the district. 

Depositaries processing tax payments in 
the FTD system are required to elect either 
the remittance or the note option. 



(c) Designation. Each financial institution 
satisfying the eligibility requirements and the application 
procedures will receive from the FRB notification of its 
specific designation as a TT&L depositary. A financial 
institution is not authorized to maintain a TT&L account 
or note balance until it has been designated as a TT&L 
depositary by the FRB. 

§ 203.5 Obligations of the depositary. 

A depositary shall: 

(a) Administer a note balance, if not participating 
in the FTD System. 

(b) Administer a TT&L account and, if applicable, 
a note balance, if participating in the FTD System. 

(c) Comply with the requirements of Section 202 
of Executive Order 11246, entitled "Equal Employment 
Opportunity" (3 GFR, 1964-1965 Comp, p. 339) as 
amended by Executive Orders 1 1375 and 12086 (3 GFR, 
1966-1970 Comp., p. 684; 3 CFR, 1978 Comp. p. 230), 
and the regulations issued thereunder at 4 1 CFR Chapter 

(d) Comply with the requirements of Section 503 
of the Rehabilitation Act of 1973, as amended, and the 
regulations issued thereunder at 41 CFR part 60- 74 1 , 
requiring Federal contractors to take affirmative action to 
employ and advance in employment qualified individuals 
with disabilities. 

(e) Comply with the requirements of Section 503 
of the Vietnam Era Veterans' Readjustment Assistance 
Act of 1972, as amended, 38 U.S.C. 4212, Executive 
Order 11701 (3 CFR 1971-1975 Comp. p. 752), and the 
regulations issued thereunder at 41 CFR parts 60-250 and 
61-250, requiring Federal contractors to take affirmative 
action to employ and advance in employment qualified 
special disabled veterans and Vietnam-era veterans. 



§203.6 Compensation for services. 

Except as provided in the procedural instructions, 
Treasury will not compensate financial institutions for 
servicing and maintaining the TT&L account, or for 
processing tax payments through the EFTPS or the FTD 
system. 

§ 203.7 Termination of agreement or change of 
election or option. 

(a) Termination by Treasury. The Secretary may 
terminate the agreement of a depositary at any time upon 
notice to that effect to that depositary, effective on the 
date set forth in the notice. 

(b) Termination or change of election or option by 
the depositary. A depositary may terminate its depositary 
agreement, or change its option or election, consistent 
with this part and the procedural instructions, by 
submitting notice to that effect in writing to the FRB 
effective at a prospective date set forth in the notice. 

§ 203.8 Application of part and procedural 
instructions. 

The terms of this part and procedural instructions issued 
pursuant to this part shall be binding on financial 
institutions that process tax payments and/ or maintain a 
note balance under this part. By accepting or originating 
Federal tax payments, the financial institution agrees to be 
bound by this part and by procedural instructions issued 
pursuant to this part. 

Subpart B— Electronic Federal Tax Payments 

§203.9 Scope of the subpart. 



This subpart prescribes the rules by which financial 
institutions shall process Federal tax payment transactions 
electronically. A financial institution does not need to be 
designated as a TT&L depositary in order to process 
electronic Federal tax payments. In addition, a financial 
institution that does process electronic Federal tax 
payments under this subpart does not thereby become a 
Federal Government depositary and shall not advertise 
itself as one because of that fact 

§ 203.10 Enrollment. 

(a) General. Taxpayers shall complete an 
enrollment process with the TFA prior to making their 
first electronic Federal tax payment 

(b) Enrollment forms. The TFA shall provide 
financial institutions and taxpayers with enrollment forms 
upon request. The taxpayer is responsible for completing 
the enrollment form, obtaining the verifications required 
on the form, and returning the enrollment form to the 
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(c) Verification. If the taxpayer elects the ACH 
debit entry method of paying taxes, an authorized 
representative of the financial institution shall verify the 
accuracy of the Financial institution routing number, 
taxpayer account number, and taxpayer account type at 
the request of the taxpayer. 

§ 203.11 Electronic payment methods. 

(a) General Electronic payment methods for 
Federal tax payments available under this subpart include 
ACH debit entries, ACH credit entries, and same-day 
payments. Any financial institution that is capable of 
originating and/or receiving transactions for these 
payment methods, by itself or through a correspondent 
financial institution, may do so on behalf of a taxpayer. 

(b) Conditions to making art electronic payment. 
Nothing contained in this part shall affect the authority of 
financial institutions to enter into contracts with their 
customers regarding the terms and conditions for 
processing payments, provided that such terms and 
conditions are not inconsistent with this subpart and 
applicable law governing the particular transaction type. 

(c) Paymen t of interest for time value of funds 
held. Treasury will not pay interest on any payments 
erroneously paid to Treasury and subsequently refunded 
to the financial institution. 



§ 203.12 Future-day 
mechanisms. 



reporting and payment 




(a) General. A financial institution may receive an 
ACH debit entry, originated by the TFA at the direction of 
the taxpayer; or, a financial institution may originate an 
ACH credit entry, at the direction of the taxpayer. 
Taxpayers will be credited for the actual amount received 
by Treasury. 

Q6) ACH debit. A financial institution receiving an 
ACH debit entry originated by the TFA shall, as 
applicable: 

(1) Timely verify the account number and 
account type contained in an ACH 
prenotification entry; 

(2) Timely and properly return a 
prenotification entry that contains an 
invalid account number or account type, or 
otherwise is erroneous or unprocessable; 

(3) Timely and accurately notify the TFA of 
incorrect information on entries received, 
using a Notification of Change entry; and 

(4) Timely and accurately return an entry not 
posted, including but not limited to, a 
return or a contested dishonored return for 
acceptable return reasons, as set forth in 



me^p^ 

(c) ACH credit. A financial institution originating 
an ACH credit entry at the direction of a taxpayer shall: 



(1) At the request of the taxpayer, originate 
either an ACH prenotification containing 
the taxpayer's identification number or a 
zero dollar ACH entry with the appropriate 
addenda record. Additional format 
information is contained in the procedural 
instructions; 

(2) Format the ACH credit entry in the ACH 
format approved by Treasury for Federal 
taxpayments; 

(3) Originate an ACH credit entry by the 
appropriate deadline, as specified by the 
FRB or Treasury, whichever is earlier, in 
order to meet the tax due date specified by 
the taxpayer; and 

(4) Provide the taxpayer, upon request, a 
transaction trace number, or some other 
method to trace the tax payment. 



(d) ACH credit reversals. Reversals may be 
initiated for a duplicate or erroneous file or entry. No 
advance approval from, or notification to, the IRS is 
required when originating an ACH credit reversal 
Documentation of reversals shall be made available as set 
forth in the procedural instructions. 

§ 203.13 Same-day reporting and payment 
mechanisms. 

(a) General. A financial institution or its 
authorized correspondent may initiate same-day reporting 
and payment transactions on behalf of taxpayers. A same- 
day payment must be received by the FRB of the district 
by the deadline established by the Treasury in the 
procedural instructions. Taxpayers will be credited for the 
actual amount received by Treasury. 

(b) Fedwire value transfer. To initiate a Fedwire 
value tax payment, the financial institution shall be a 
Fedwire participant and shall comply with the FRB ' s 
Fedwire format for tax payments. The taxpayer's 
financial institution shall provide the taxpayer, upon 
request, the IMAD and the ETA reference numbers for a 
Fedwire value transfer. The financial institution may 
obtain the ETA reference number for Fedwire value 
transfers from its FRB by supplying the related IMAD 
number. Fedwire value transfers settle immediately to the 
TGA and thus are not credited to a depositary's main note 
balance. 

(c) Fedwire non-value transaction. By initiating a 
Fedwire non- value transaction, a financial institution 
authorizes the FRB of the district to debit its Federal 
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Reserve account or, for a TT&L depositary, to debit the 
Federal Reserve account of the depositary or its 
designated correspondent financial institution, for the 
amount of the tax payment specified in the transactor 
To initiate a Fedwire non- value transaction, the financial 
institution shall be a Fedwire participant and shall comply 
with the FRB's Fedwire format for tax payments. The 
taxpayer's financial institution shall provide the taxpayer, 
upon request, the IMAD and ETA reference numbers for 
the Fedwire non-value transaction. The financial 
institution may obtain the ETA reference number for 
Fedwire non-value transactions from its FRB by supplying 
the related IMAD number. 

(1) For a note option depositary using a 
Fedwire non-value transaction, me tax 
payment amount will be credited to the 
depositary's main note balance on the day 
of the transaction. 

(2) For a remittance option depositary using a 
Fedwire non-value transaction, the tax 
payment amount will be debited from the 
Federal Reserve account of the depositary 
or the depositary's designated 
correspondent and credited to the TG A on 
the day of the transaction. 

(3) For a non-TT&L depositary financial 
institution using a Fedwire nonvalue 
to 

debited from the financial institution's 
Federal Reserve account and credited to 
the TGA on the day of the transaction. 

(d) Direct Access transaction. By initiating a 
Direct Access transaction, a financial institution 
authorizes the FRB of the district to debit its Federal 
Reserve account or, for a TT&L depositary, to debit the 
Federal Reserve account of the depositary or its 
designated correspondent financial institution for the 
amount of the tax payment specified in the transaction. 
The taxpayer's financial institution shall provide the 
taxpayer, upon request, the ETA reference number for the 
Direct Access transaction. 

( 1 ) For a note option depositary using a Direct 
Access transaction, the tax payment 
amount will be credited to the depositary's 
main note balance on the day of the 
transaction. 

(2) For a remittance option depositary or a 
non-TT&L depositary financial institution 
using a Direct Access transaction, the tax 
payment amount will be debited from the 
Federal Reserve account of the financial 
institution or its designated correspondent 
financial institution, and credited to the 
TGA on the day of the transaction. 



(e) Cancellations and reversals. In addition to 
cancellations due to insufficient funds in the financial 
institution's Federal Reserve account, the FRB may 
reverse a same-day transaction: 

(1) If the transaction: 

(i) Is originated by a financial 
institution after the deadline 
established by the Treasury in the 
procedural instructions; 

(ii) Has an unenrolled taxpayer 
identification number; or 

(iii) Does not meet the edit and format 
requirements set forth in the 
procedural instructions; or, 



(2) 



At the direction 
following reasons: 



of the IRS, for the 



(3) 



(i) Incorrect taxpayer name; 

(ii) Overpayment; or 

(iii) Unidentified payment; or, 

At the request of the financial Institution 
that sent the same-day transaction, if the 
request is made prior to the deadline 
established by Treasury in the procedural 
instructions on the day the payment was 
made. 



(f) Other than as stated in paragraph (e) ; of this 
section, Treasury is not obligated to reverse all or any part 
ofapayment. 

[63 FR 5650, Feb. 3, 1998, as amended at 67 FR 
11576, Mar. 15,2002] 

§ 203.14 Electronic Federal Tax Payment System 
: interest assessments. 

(a) Circumstances subject to interest assessments. 
Treasury may assess interest on a financial institution in 
instances where a taxpayer that failed to meet a tax due 
date proves to the IRS that the delivery of tax payment 
instructions to the financial institution was timely and that 
the taxpayer satisfied the conditions imposed by the 
financial institution pursuant to § 203.1 1(b). Treasury 
alsomay assess interest where a financial institution failed 
to respond to an ACH prenotification entry on an ACH 
debit as required in § 203.12(b) or failed to originate an 
ACH prenotification or zero dollar entry on an ACH 
credit as described in § 203 . 1 2(c) which then resulted in 
a late payment. 

(b) Calculation of interest assessment Any interest 
assessed under this section will be at the TT&L rate. The 
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interest will be assessed from the day the taxpayer 
specified that its payment should settle to the Treasury 
until the receipt of the payment by Treasury, subject to 
the following limitations: 

For ACH debit transactions, interest will be 
limited to no more than seven calendar days; for 
ACH credit and same-day transactions, interest 
will be limited to no more than 45 calendar days. 
The limitation of liability in this paragraph does 
not apply to any interest assessment in which there 
is an indication of fraud, the presentation of a false 
claim, or misrepresentation or embezzlement on 
the part of the financial institution or any 
employee or agent of the financial institution. 

{(^Authorization to assess interest A financial 
institution that processes Federal tax payments made by 
electronic payment methods under this subpart is deemed 
to authorize the FRB to debit its Federal Reserve account 
or the account of its designated correspondent financial 
institution for any : interest assessed under this section. 
Upon the direction of Treasury, the FRB shall debit the 
Federal Reserve account of the financial institution or the 
account of its designated correspondent financial 
institution for the amount of the assessed interest 



ACH transaction to debit the TGA without the prior 
written permission of Treasury. Unauthorized entries 
under this section do not include reversal entries of 
previously initiated ACH credits authorized in § 
203.12(d). 

(b) Liability. A financial institution that originates 
an unauthorized ACH entry that debits the TGA shall be 
liable to Treasury for the amount of the transaction and 
shall be liable for interest charges as specified in 
paragraph (d) of this section. 

(c) Authorization to recover principal and assess 
interest charge. By initiating unauthorized debits to the 
TGA through the ACH, a financial institution is deemed 
to authorize the FRB to debit its Federal Reserve account 
or the account of its designated correspondent financial 
institution for any principal and, if applicable, an interest 
charge assessed by Treasury under this section. 

{A) Interest charge calculation. The interest charge 
shall be at a rate equal to the Federal funds rate plus two 
percent The interest charge shall be assessed for each 
calendar day from the day the TGA was debited to the day 
the TGA is recredited with the full amount of principal 
due. 



interest 



(d) Circumstances not subject to the assessment of § 203.16 Appeal and dispute resolution. 




(1) Treasury will not assess interest on a 
taxpayer 's financial institution if a taxpayer 
fails to meet a tax due date because the 
taxpayer has not satisfied conditions 
imposed by the financial institution 
pursuant to § 203.11(b) and the financial 
institution has not contributed to the delay. 
The burden is on the financial institution to 
establish, pursuant to the procedures in § 
203.16, that the taxpayer has not satisfied 
the conditions and that the financial 
institution has not contributed to the delay. 

(2) Treasury will not assess interest on a 
financial institution if the delay causing the 
interest assessment is due to the FRB or the 
TFA and the financial institution did not 
contribute to the delay. The burden is on 
the financial institution to establish, 
pursuant to the procedures in § 203 . 16, that 
it did not cause or contribute to the delay. 

§ 203.15 Prohibited debits through the Automated 
Clearing House. 

(a) General The Treasury has instituted 
operational safeguards to scrutinize all entries that remove 
funds from the TGA. In the event funds are removed from 
the TGA without authority, this section sets forth the 
liability of financial institutions originating such entries. 
Accordingly, a financial institution shall not originate an 



(a) Contest. A financial institutionmay contest any 
interest assessed under § 203. 14, any principal or interest 
assessed under § 203.15, or any late fees assessed under 
§203.20. The financial institution shall submit information 
supporting its position and the relief sought The 
information must be received, in writing, by the Treasury 
officer or fiscal agent identified in the procedural 
instructions, no later than 90 calendar days after the date 
the FRB debits the reserve account of the financial 
institution under §§203.14, 203.15, or 203. 20. The 
Treasury officer or fiscal agent will: uphold the 
assessment, or reverse the assessment, or modify the 
assessment, or mandate other action. 

(b) Appeal. The financial institution may appeal 
the decision to Treasury as set forth in the procedural 
instructions. No further administrative review of the 
Treasury's decision is available under this Part. 

(c) Recoveries. In the event of an over or under 
recovery of either interest, principal, or late fees, Treasury 
will instruct the FRB to credit or debit the Federal 
Reserve account of the financial institution or its 
designated correspondent financial institution, as 
appropriate. 
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Subpart C— federal Tax Deposits 

§203.17 Scope of the subpart. 

This subpart applies to all depositaries that accept FTD 

coupons and governs the acceptance and processing of 

those coupons. 

§ 203.18 Tax deposits using Federal Tax Deposit 

coupons. 

(a) FTD coupons. A depositary that accepts FTD (7) 

coupons, through any of its offices that accept demand 
and/or savings deposits, shall: 



(1) 



(2) 



(3) 



(4) 



(5) 



(6) 



Accept from a taxpayer, cash, a postal 
money order drawn to the order of the 
depositary, or a check or draft drawn on 
and to the order of the depositary, covering 
an amount to be deposited as Federal taxes 
when accompanied by an FTD coupon on 
which the amount of the deposit has been 
properly entered in the space provided. A 
depositary may accept, at its discretion, a 
check drawn on another financial 
institution, but it does so at its option and 
absorbs for its own account any float and 
other costs involved. 

Issue a counter receipt when requested to 
do so by a taxpayer that makes an FTD 
deposit over the counter. 

Place a stamp impression on the face of 
each FTD coupon in the space provided. 
The stamp shall reflect the date on which 
the tax deposit was received and the name 
and location of the depositary. The 
timeliness of the tax payment will be 
determined by reference to the date 
stamped by the depositary on the FTD 
coupon. 

Credit, on the date of receipt, all FTD 
deposits to the TT&L account and 
administer that account pursuant to the 
provisions of this part. 



Forward, each day, to the IRS Center 
servicing the geographical area in which 
the depositary is located, the FTD coupons 
for all FTD deposits received that day. The 
FTD coupons shall be accompanied by an 
advice of credit reflecting the total amount 
of all FTD coupons. 

Establish an adequate record of all FTD 
deposits prior to transmittal to the IRS 
Center so that the depositary will be able to 
identify deposits in the event tax deposit 
coupons are lost in shipment. For tracking 
purposes, a record shall be made of each 



(8) 



FTD deposit showing, at a minimum, the 
date of deposit, the taxpayer identification 
number, and the amount of the deposit. 
The depositary's copy of the advice of 
credit may be used to provide the 
necessary information if individual 
deposits are listed separately, showing 
date, taxpayer identification number, and 
amount. 

Deliver its advices of credit to the FRB by 
the cutoff hour designated by the FRB for 
receipt of advices. 

Not accept compensation from taxpayers 
for accepting FTDs and handling them as 
required by this section. 



(b) FTD deposits with Federal Reserve Banks. An 
FRBshall: 

(1) Accept an FTD directly from a taxpayer 
when such tax deposit is: 

(i) Mailed or delivered by a taxpayer; 
and 

(ii) Provided in the form of cash or a 
check or postal money order 
payable to the order of that FRB; 
and, 

(iii) Accompanied by an FTD coupon 
on which the amount of the tax 
deposit has been properly entered 
in the space provided. 

(2) Issue a counter receipt, when requested to 
do so by a taxpayer that makes an FTD 
over the counter; and, 

(3) Place, in the space provided on the face of 
each FTD coupon accepted directly from a 
taxpayer, a stamp impression reflecting the 
name of the FRB and the date on which the 
tax deposit will be credited to the TGA. 
Timeliness of the Federal tax payment will 
be determined by this date. However, if a 
deposit is mailed to an FRB, it shall be 
subject to the "Timely mailing treated as 
timely filing and paying" clause of the 
Internal Revenue Code, 26 U.S.C. 7502; 
and, 

(4) Credit the TGA with the amount of the tax 
payment; 

(i) On the date the payment is 
received, if payment is made in 
cash; or, 
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(ii) On the date the proceeds of the tax 
payment are collected, if payment is 
made by postal money order or 
check. 



§ 203.19 Note option. 




(a) Late delivery of advices of credit. If an advice 
of credit does not arrive at the FRB before the designated 
cutoff hour for receipt of such advices, the FRB will post 
the funds to the main note balance as of the next business 
day after the date on the advice of credit. This is the date 
on which funds will begin to earn interest for Treasury. 

(b) Transfer of funds from TT&L account to the 
main note balance. For a depositary selecting the note 
option, funds equivalent to the amount of deposits 
credited by a depositary to the TT&L account shall be 
withdrawn by the depositary and credited to the main note 
balance on the business day following the receipt of the 
tax payment 

[67 FR 11576, Mar. 15,2002] 

§ 203.20 Remittance option* 

(a) FTD late fee. If an advice of credit does not 
arrive at the FRB before the designated cutoff hour for 
receipt of such advices, an FTD late fee in the form of 
interest at the TT&L rate will be assessed for each day's 
delay in receipt of such advice. Upon the direction of 
Treasury, the FRB shall debit the Federal Reserve account 
of the financial institution or the account of its designated 
correspondent financial institution for the amount of the 
late fee. 

(b) Withdrawals. For a depositary selecting the 
Remittance Option, the amount of deposits credited by a 
depositary to the TT&L account will be withdrawn upon 
receipt by the FRB of the advices of credit. The FRB will 
charge the depositary's Federal Reserve account or the 
account of the depositary's designated correspondent 
financial institution. 

Subpart 3D— Investment Program and Collateral 

Security Requirements for Treasury Tax and Loan 
.Depositaries .: 

§ 203.21 Scope of the subpart. 

This subpart provides rules for TT&L depositaries on 
crediting main note balances under the various payment 
methods; debiting main note balances; maintaining term 
note balances; and pledging collateral security. 

[67 FR 11576, Mar. 15,2002] 

§ 203.22 Sources of balances. 

Depositaries electing to participate in the investment 
program can receive Treasury ' s investments in obligations 



of the depositary from the following sources: 

(a) FTDs that have been credited to the TT&L 
account pursuant to subpart C of this part; 

(b) EFTPS ACH credit and debit transactions, 
Fedwire non-value transactions, and Direct Access 
transactions pursuant to subpart B of this part; 

(c) Direct investments and special direct 
investments pursuant to subpart D of this part; and 

(d) Other excess Treasury operating funds. 

[63 FR5650, Feb. 3, 1998, as amended at 67 FR 
11576, Mar. 15, 2002] 

§ 203.23 Note balance, 

(a) Additions. Treasury will invest funds in 
obligations of depositaries selecting the note option. Such 
obligations shall be in the form of openended, interest- 
bearing notes; and additions and reductions will be 
reflected on the books of the FRB of the district. 

(1) FTD system. A depositary processing tax 
deposits using the FTD system and electing 
the note option shall debit the TT&L 
account and credit its main note balance as 
stated in §203. 19(b). 



(2) EFTPS- 



(0 



A CH debit and A CH credit A note 
option depositary processing 
EFTPS ACH debit entries and/or 
ACH credit entries shall credit its 
main note balance for the value of 
the transactions on the date that an 
exchange of funds is reflected on 
the books of the Federal Reserve 
Bank of the district. Financial 
institutions may refer to the 
procedural instructions for 
information on how to ascertain the 
amount of the credit to the main 
note balance. 

Fedwire non-value and Direct 
Access. A note option depositary 
processing Fedwire non-value 
and/or Direct Access transactions 
pursuant to subpart B of this part 
shall credit its main note balance 
and debit its customer's account for 
the value of the transactions on the 
date ETA receives and processes 
the transactions. 



(b) Other additions. Other funds from Treasury 
may be offered from time to time to certain note option 



(ii) 



FTDP20 



2005 ACH RULES 



FEDERAL TAX DEPOSIT PA YMENTS 



depositaries through direct investments, special direct 
investments, or other investment programs. 

(c) Main note balance withdrawals. The amount of 
the mainnote balance shall be payable on demand without 
prior notice. Galls for payment on the note will be by 
direction of the Secretary through the FRBs. On behalf of 
Treasury, the FRB shall charge the reserve account of the 
depositary or the depositary's designated correspondent 
on the day specified in the call for payment. 

(d) Interest. A main note balance shall bear interest 
at the TT&L rate. Such interest is payable by a charge to 
the Federal Reserve account of the depositary or its 
designated correspondent in the manner prescribed in the 
procedural instructions. 

(e) Maximum balance— 



(i) 



(2) 



(3) 



Note option depositaries. A depositary 
selecting the note option shall establish a 
maximum for its main note balance by 
providing notice to that effect in writing to 
the FRB of the district. The maximum 
balance is me amount of funds for which a 
main note option depositary is willing to 
provide collateral in accordance with § 
203.24(c)(1). The depositary shall provide 
the advance notice required in the 
procedural instructions before reducing the 
established maximum balance unless it is a 
reduction resulting from a collateral re- 
evaluation as determined by the 
depositary's FRB. That portion of any 
advice of credit or EFTPS tax payment, 
which, when posted at the FRB, would 
cause the main note balance to exceed the 
maximumbalance amount specified by the 
depositary, will be withdrawn by the FRB 
thatday. 

Direct investment depositaries. A main 
note option depositary that participates in 
direct investment shall set amaximum for 
its mainnote balance for direct investment 
purposes which is higher than its peak 
balance normally generated by the 
depositary's advices of credit and EFTPS 
tax payment inflow. The direct investment 
note option depositary shall provide the 
advance notice required in the procedural 
instructions before reducing the established 
maximumbalance. 



Special direct investment depositaries. 
Special direct investments, when credited 
to the main note balance, shall not be 
considered in setting the amount of the 
maximum balance or in determining the 
amounts to be withdrawn where a 



depositary's maximum balance is 
exceeded. 

(f) Term investment option. Treasury may, from 
time to time, invest excess operating funds in obligations 
ofdepositaries selecting the term investment option. Such 
obligations shall be in the form of interest-bearing notes 
payable upon a predetermined period of time not to 
exceed 90 days. Such notes shall bear interest at a rate 
prescribed by the Secretary by auction or otherwise taking 
into consideration prevailing market interest rates. 

[63 FR 5650, Feb. 3, 1998, as amended at 67 FR 
11576, Mar. 15,2002] 

§ 203.24 Collateral security requirements. 

Financial institutions that process EFTPS tax payments, 
but are not TT&L depositaries, have no collateral 
requirements under this part. Financial institutions that are 
note option depositaries or remittance option depositaries 
have collateral security requirements, as follows: 

(a) Note option— main note balance— 

(1) FTD deposits and EFTPS tax payments. A 
depositary shall pledge collateral security 
in accordance with the requirements of 
paragraphs (d)(1), (e), and (f) of this 
section in an amount that is sufficient to 
cover the pre-established maximum 
balance for the main note balance, and, if 
applicable, the losing balance in the TT&L 
account which exceeds recognized 
insurance coverage. Depositaries shall 
pledge collateral for the full amount of the 
maxr^ time the 

maximum balance is established. If the 
depositary maintains a TT&L account, the 
depositary shall pledge collateral security 
before crediting deposits to the TT&L 
account. 

(2) Direct investments. A note option 
depositary that participates in direct 
investment is not required to pledge 
collateral continuously in the amount of the 
pre-established maximum balance. 
However, each note option depositary 
participating in direct investment shall 
pledge, no later than the day the direct 
investment is placed, the additional 
collateral in accordance with paragraphs 
(d)(1), (e), and (f) of this section to cover 
me total main note balance including those 
funds received through direct investment. 
If a direct investment depositary has a 
history of frequent collateral deficiencies, 
it shall fully collateralize its maximum 
balance at all times. 
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(3) Special direct investments. Before special 
direct investments are credited to a 
depositary's main note balance, the note 
option depositary shall pledge collateral 
security, in accordance with the 
requirements of paragraphs (d)(2) and (f) 
of this section, to cover 100 percent of the 
amount of the special direct investments to 
be received. 

(b) Note option—term note balance. Each note 
option depositary participating in the term investment 
program shall pledge, prior to the time the term 
investment is placed, collateral in accordance with 
paragraphs (d) (1), (e), and (f) of this section sufficient to 
cover the total term note balance. 

(c) Remittance option. Prior to crediting FTD 
deposits to the TT&L account, a remittance option 
depositary shall pledge collateral security in accordance 
with the requirements of paragraph (c)(1), (d), and (e). of 
this section in an amount which is sufficient to cover the 
balance in the TT&L account at the close of business each 
day, less recognized insurance coverage. 

(d) Deposits of securities, 

(1) Collateral security required under 
paragraphs (a)(1), (2), (b), and (c) of this 
section shall be deposited with the FRB of 
the district, or, where appropriate, with a 
custodian or custodians within the United 
States designated by the FRB, under terms 
and conditions prescribed by the FRB 

(2) (i) Collateral security required under 

paragraph (a)(3) of this section shall be 
pledged under a written security 
agreement on a form provided by the 
FRB of the district. The collateral 
security pledged to satisfy the 
requirements of paragraph (a)(3) of this 
section may remain in the pledging 
depositary's possession and the fact 
that it has been pledged shall be 
evidenced by advices of custody to be 
incorporated by reference in the written 
security agreement. The written 
security agreement and all advices of 
custody covering collateral security 
pledged under that agreement shall be 
provided by the depositary to the FRB 
of the district. Collateral security 
pledged under the agreement shall not 
be substituted for or released without 
the advance approval of the FRB of the 
district, and any collateral security 
subject to the security agreement shall 
remain so subject until an approved 
substitution is made. No substitution or 
release shall be approved until an 



advice of custody containing the 
description required by the written 
security agreement is received by the 
FRB of the district 

(ii) Treasury's security interest in collateral 
security pledged by a depositary in 
accordance with paragraph (c)(2)(i) of 
this section to secure special direct 
investments is perfected without 23 
Treasury taking possession of the 
collateral security for a period not to 
exceed 21 calendar days from the day 
of the depositary's receipt of the 
special direct investment. 

(e) Acceptable securities. Types and valuations of 
acceptable collateral security are addressed in 31 CFR 
part 380. For a current list of acceptable classes of 
securities and instruments described in 3 1 CFR part 380 
and their valuations, see the Bureau of the Public Debt's 
web site at www.publicdebt.treas.gov. 

(f) Assignment of securities. A TT&L depositary 
that pledges acceptable securities which are not negotiable 
without its endorsement or assignment may furnish, in lieu 
of placing its unqualified endorsement on each security, 
an appropriate resolution and irrevocable power of 
attorney authorizing the FRB to assign the securities. The 
resolution and power of attorney shall conform to such 
terms and conditions as the FRB shall prescribe. 

(g) Effecting payments ofprincipal and interest on 
securities pledged as collateral 



(1) General If the depositary fails to pay, when 
due, the whole or any part of the funds 
received by it for credit to the TT&L 
account, and/or if applicable, its note 
balance; or otherwise violates or fails to 
perform any of the terms of this part, or fails 
to pay when due amounts owed to the 
United States or the United States Treasury; 
or if the depositary is closed for business by 
regulatory action or by proper corporate 
action, or in the event that a receiver, 
conservator, liquidator or any other officer 
is appointed; then the Treasury, without 
notice or demand, may sell, or otherwise 
collect the proceeds of all or part of the 
collateral, including additions and 
substitutions; and apply the proceeds, to 
satisfy any claims of the United States 
against the depositary. All principal and 
interestpayments on any security pledged to 
protect the note balance (if applicable) 
and/or the TT&L account (if applicable), 
due as of the date of the insolvency or 
closure, or thereafter becoming due, shall be 
held separate and apart from any other 
assets and shall constitute a part of the 
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pledged security available to satisfy any 
claim of the United States. 

(2) Payment procedures. 



(i) Subject to the waiver in paragraph 
(f)(2)(iii) of this section, each 
depositary (including, with respect to 
such depositary, an assignee for the 
benefit of creditors, trustee in 
bankruptcy, or a receiver in equity) 
shall immediately remit each payment 
of principal and/or interest received by 
it with respect to collateral pledged 
pursuant to this section to the FRB of 
the district, as fiscal agent of the United 
States, and in any event shall so remit 
no later than 10 days after receipt of 
such a payment. 

(ii) Subject to the waiver in paragraph 
(f)(2)(iii) of this section, each obligor 
on a security ledged by a depositary 
pursuant to this section, upon 
notification that the Treasury is entitled 
to any payment associated with that 
pledged security, shall make each 
payment of principal and/or interest 
due with respect to such security 
directly to the FRB of the district, as 
fiscal agent of the United States. 

(hi) The requirements of paragraphs 
(f)(2)(i) and (ii) of this section are 
hereby waived for only so long as a 
pledging depositary avoids both 
termination from the program under 
§203.7; and also, those circumstances 
identified in paragraph (f)(1) which 
may lead to the collection of the 
proceeds of collateral or the waiver is 
otherwise terminated by Treasury. 



[63 FR 5650, Feb. 3, 1998, as amended at 65 FR 
55429, Sept. 13, 2000; 67 FR 11577, Mar. 15,2002] 
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ELECTRONIC FEDERAL TAX 
PAYMENT SYSTEM 
Risk Issues For- Financial Institutions: 
ACH Credits And ACH Debits 



Corporate taxpayers are being mandated over a series of 
years, 1995 - 1999, to begin paying their taxes 
electronically via the Department of the Treasury's 
Electronic Federal Tax Payment System (EFTPS). 
Internal Revenue Service (IRS) regulations mandate that 
all Federal depository tax deposits be made electronically 
when the taxpayer's annual employment tax deposits 
exceed the dollar threshold for a specific determination 
period. 

Financial institutions should anticipate that taxpayers will 
be contacting them with questions concerning EFTPS. 
This document provides assistance to financial institutions 
in evaluating whether to initiate tax payments via ACH 
credit transactions on behalf of their corporate customers, 
and helps financial institutions provide information to 
corporate customers on the options of paying by ACH 
credit or ACH debit. For more information on ACH risk 
management techniques, the Revised ACH Risk 
Management Handbook can be purchased by calling 
Payments Publications at j -800-487-9 180. 

ACH Credit 

An ACH credit payment under EFTPS will transfer funds 
from the corporate taxpayer's account at its financial 
institution to the IRS. A financial institution transmitting 
an ACH credit entry for a Federal tax payment on behalf 
of its corporate customer would be the ODFI of the 
transaction. 

The ODFI incurs credit exposure for the period of time 
between the transmission of the ACH credit to the ACH 
Operator, until the company funds the account 
Generally, funding of the account occurs on the settlement 
day, which is one to two business days after initiation of 
the credit entry. The NACHA Operating Rules do not 
allow the ODFI to call back (reverse) ACH credits for 
failure of the Originator to fund its account at the ODFI. 
Therefore, the ODFI is financially responsible for the 
credit entry for up to two days until it receives funding 
from the Originator. 

In many respects, this exposure is equivalent to granting 
an unsecured short term loan for that period. Financial 
institutions have suffered only minor losses due to the 
failure of one of its Originators to fund its account for an 
ACH credit file. However, if a company went bankrupt or 
failed to fund the account between the date of origination 
and the date of settlement, then the ODFI could suffer a 
loss. 



If a tax payment is made by ACH credit and the taxpayer 
defaults, the ODFI currently has no way of retrieving the 
funds from the taxing authority. The ODFI could request 
the funds to be returned, but it is unlikely that the funds 
would be returned by the taxing authority. 

It is important for financial institutions to recognize the 
potential exposure a financial institution faces when 
initiating tax payments and to take action to control that 
risk. Financial institutions should follow the adage, 
"Know Your Customer." ODFIs need to determine how 
to best manage the credit risk associated with ACH credit 
origination. Establishing exposure limits for its corporate 
customers, as required by a NACHA Operating Rule 
amendment (effective September 20, 1996), will help to 
manage mis risk. Exposure limits could be determined, 
for example, by performing a credit analysis of the 
Originator, or by implementing a "risk pooling" policy 
which allows ACH Originators initiating low value 
payments to have minimum exposure limits. In the 
absence of a credit review, requiring the Originator of 
ACH credits to fund its account prior to settlement date 
would also help reduce the ODFFs risk. Financial 
institutions should be cautious about deciding to initiate 
ACH credit tax payments, particularly if this is the first 
time they will be taking on the responsibilities of an ODFI 
of an ACH transaction. ODFIs should review their 
agreements with their corporate customers to ensure that 

liabilities, warranties, and other responsibilities are clearly 
defined. 

-ACH. Debit . 

An ACH debit transaction under EFTPS will transfer 
funds to the IRS from the corporate taxpayer's account at 
its financial institution. A financial institution receiving 
an ACH debit transaction for a Federal tax payment of a 
corporate customer is the RDFI of the debit transaction. 

The predominant risk to the RDFI in processing ACH 
debits is operational risk. The RDFI must be able to 
determine whether or not to return an ACH debit by its 
ACH Operator's deposit deadline for the return entry to 
be made available to the IRS' s Financial Agent no later 
than the opening of business on the second banking day 
following the settlement date of the debit entry. Failure to 
return an item for insufficient funds or other reason by 
that time may result in a loss for the RDFI if the IRS 
dishonors the return as untimely. This type of risk should 
be c ontrolled through the implementation of strict 
operational procedures that ensure ACH return deadlines 
are met. RDFIs should be aware that the corporate 
taxpayer has initiated the debit entry by contacting the 
IRS's Financial Agent and letting them know the amount 
to debit from its account. 

The RDFI may choose to assume some credit risk in 
processing ACH debits by allowing an ACH debit to post, 
even if it overdraws the Receiver's account. This is a 
common practice among some financial institutions which 
provide the same service for customers whose checks 
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overdraw their accounts. However, it is important to 
recognize the credit risk a financial institution takes by 
allowing this to happen. If a corporate tax payment is 
made by ACH debit and the taxpayer does not have 
sufficient funds on the settlement day to cover the 
payment, the taxpayer's financial institution can control 
its risk by returning the item to the taxing authority's 
financial institution, who in turn will charge back the 
payment. 
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EFTPS HIGHLIGHTS 



EFTPS Taxpayer Customer Service Center 

24 hours a day, 7 days a week 
1-800-555-4477 



EFTPS Financial Institution Helpline Service 

Call from 8:30 a.m. to 8:00 p.m. Eastern Time 

Monday through Friday 

1-800-605-9876 



EFTPS Highlights 

The following is a Treasury Department information sheet on EFTPS: Critical information for any financial institution 
representative who has contact with customers who make Federal Tax Deposits. 

EFTPS is a secure and easy way for business and individual taxpayers to pay Federal business taxes electronically- 
online or by phone - from the convenience of office or home, 24 hours a day, 7 days a week. With EFTPS, the current 
paper-based tax system is converted into an electronic system - one in which tax payment information and 'funds move 
electronically. 

EFTPS is a service provided free by the U.S. Department of the Treasury. 
About EFTPS... 

1 . IRS regulations require businesses that paid at least $200,000 in payroll taxes in any given year to pay all their 

Federal business taxes electronically through EFTP S beginning January 1 of the second succeeding year. These 
taxpayers receive notifications and enrollment forms from IRS. Penalties for the failure to make deposits using 
EFTPS will be assessed for those taxpayers required to make federal tax payments electronically through 
EFTPS. 



2. 

3. 
4. 

5. 



Any taxpayer may voluntarily enroll by visiting EFTPS-OnLine at www.eftps.gov., or calling the EFTPS 
Customer Service Center and requesting an enrollment form. 

An enrollment should be completed for each Taxpayer Identification Number (EIN or SSN). 

EFTPS is easy to use. The taxpayer controls the initiation of the tax payment. Neither EFTPS nor IRS has 
unauthorized access to the taxpayer's bank account. The taxpayer is in full control of initiating all tax payments. 

EFTPS is designed for all business taxpayers and is especially useful for individual taxpayers making 1 040 ES 
quarterly payments. 



For questions about EFTPS... call EFTPS Customer Service, 24 hours a day, 7 days a week 

1-800-555-4477 

EFTPS- secure, easy to use.. .the taxpayer is in control of the payment... 




1. 

2. 
3. 
4. 



The taxpayer must make their tax payment into EFTPS by 8:00pm ET at least one calendar day prior to tax due 
date, before an ACH Debit can be initiated. 

Taxpayers can pay taxes through EFTPS via the Internet or by voice response with a 

The Internet feature of EFTPS is very easy to use and requires an Internet connection and secure browser. 

The voice response system (through the phone) is simple to use, guiding the taxpayer step-by-step through the 
tax payment process. 

Taxpayers can use a payment scheduling capability which offers an opportunity to schedule their tax payments 
for up to 1 20 business days in advance of tax due date for businesses and 365 days in advance for individuals . 
The ACH debit tax payment is then initiated and posts against the taxpayer's bank account on the tax due date 
indicated. 
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6 With EFTPS, the taxpayer is responsible for: 

• recording the acknowledgement number received upon completion of their tax payment 

• ensuring their bank account has sufficient funds to cover the tax payment amount 

7 If the taxpayer has fulfilled these requirements, their liability and responsibility are satisfied. Any delays 
subsequent to their tax payment are not the responsibility of the taxpayer. 

ACHReversals 

NOTE: The IRS now aUowsACH cremt reversals for duplicate or erron^ 

ACH credit reversals must be in accordance with the NACHA Operating Rules. No prior approval is needed from the 

IRS to initiate an ACH credit reversal. 

EFTPS-Same Day Pay 

1. Same Day Payments can be used by enroUed taxpayers as a backup to * e ^^ebi^eto p^^ 

options or as a primary payment mechanism. Taxpayers are automatically enrolled for EFTPS-Same Day Pay 
when they submit their enrollment form. 

2 The Same Day PaymentmechamsmFedwneFm^^ 

Vahie tax depbsit tnessages. The payment mechanisms are driven by whemer me funds settle nnmediately 
(Value Fedwire) or at the end of the day through the TIP Program (Non-Value Fedwire). 

3. For more information. Please contact your Fedwire operations area or your local Federal Reserve Bank 

Operations area. 
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Tax Payment (TXP) 
Banking Convention 

A Guide for Formatting Electronic Tax Payments 



Bankers EDI Council 



©1996 

National Automated Clearing House Association 

13665 Dulles Technology Drive, Suite 300, Herndon, VA 20171 

703/561-1 100 (phone), 703/787-0996 (fax) 

All Rights Reserved 

Conditions of use are within the control of the individual user. 

There is no warranty, expressed or implied, in connection with making this Guide available. 



FTDP29 



2005 ACH RULES FEDERAL TAX DEPOSIT PAYMENTS 



PREFACE 

The Tax Payment (TXP) Banking Convention was prepared by the Bankers EDI Council of the National Automated 
Clearing House Association (NACHA), in cooperation with the Federation of Tax Administrators (FTA) and the 
Committee on State Taxation (Cost), to provide a standard format for businesses to electronically remit tax payment 
information with tax payments to state taxing authorities via the Automated Clearing House (ACH) Network using the 
NACHA CCD+ format. The convention, approved by the Bankers EDI Council on March 7, 1990, has since been 
adopted by county, city and municipal taxing authorities for their electronic tax payment programs. 

Subsequent to the approval and adoption of the Tax Payment (TXP) Banking Convention, it was submitted to the 
Accredited Standards Committee (ASC) X12 of the American National Standards Institute (ANSI) for development as 
a data segment. This banking convention, as it applies for use within the Addenda Record of the CCD+ format, was 
approved and published as the Tax Payment (TXP) Data Segment for use within Table 2 of the ASC XI 2 Payment 
Order/Remittance Advice (820) Transaction Set. The availability of the TXP Data Segment as anX12 standard enables 
taxing authorities to offer business taxpayers an option to remit tax payments and payment information via the ACH 
Network using the 820 Transaction Set conveyed within the Addenda Records of the CTX format. 

In anticipation of the launch of the Electronic Federal Tax Payment System (EFTPS), slight modifications were made 
to the Tax Payment (TXP) Banking Convention and Data Segment in 1995 in order to support Federal tax reporting 
needs. These enhancements were such that the data elements (fields) TXP04, TXP06 and TXP08 « Amount Type, as 
identified in the Tax Payment (TXP) Banking Convention; Tax Information ID Number , as identified in the Tax 
Payment (TXP) Data Segment under ASC X 1 2 standards (3 060 Subrelease 1 )- could accommodate longer code strings. 
These code values, which are defined by taxing authorities for internal financial processing purposes, qualify the Tax 
Amount(s) reported in data elements (fields) TXP05, TXP07 and TXP09, respectively. State taxing authorities typically 
use a one-character code in these data elements. The reporting requirements of EFTPS necessitated the expansion of 
the field sizes of these data elements for the Federal implementation of the convention. 

This solution, arrived at through the cooperative efforts of the financial services industry, taxing authorities and the EDI 
standards development community, allows business taxpayers to use the same data structure to electronically remit tax 
payments and information to Federal, state and local taxing authorities. This approach serves the goals of operational 
and processing efficiency, ease of implementation and support, and the acceptance of national standards for electronic 
data interchange (EDI). It should be noted that some taxing authorities may have modified this convention for their 
implementation purposes. Taxpayers should confirm the use of the Tax Payment (TXP) Banking Convention as herein 
published with the taxing authorities to which they are originating tax payments. 
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TAX PAYMENTS 

The Tax Payment (TXP) Banking Convention contains the format, definitions and implementation suggestions for 
businesses to electronically remit tax payments and information to taxing authorities via the Automated Clearing House 
(ACH) Network using the CCD+ format. This method allows the business taxpayer to transmit an ACH credit payment 
with remittance detail in a single transaction. This document addresses the use of the Tax Payment (TXP) Banking 
Convention within the CCD+ format, but does not detail the use of the Tax Payment (TXP) Data Segment within the 
ASC X12 Payment Order/Remittance Advice (820) Transaction Set for transmission using the NACHA CTX format. 

XL BACKGROUND 

Since its approval in 1990, the Tax Payment (TXP) Banking Convention has been adopted by the majority of stateand 
many local taxing authorities as the standard for businesses to electronically remit tax payment information in a CCD+ 
transaction. Through the Electronic Federal Tax Payment System (EFTPS) and its prototype, TAXLINK, the Federal 
Government has established a nationwide program for the collection of tax revenue and has incorporated this convention 
for business tax payments originated by ACH credit using the CCD+ format. The acceptance of ACH credit and 
alternative payment methods, such as ACH debit and wire transfer (e.g., Fedwire), are determined by the individual 
taxing authorities. Criteria for the type of taxes that can or must be paid electromcally 
mandates for participation are established by me taxing 

Used in the state and Federal tax payment arenas, EDI and EFT technologies in general and the Tax Payment (TXP) 
Banking Convention in particular are increasingly being embraced by county, city and municipal taxing authorities. As 
the relative cost of technology continues to decrease and more organizations implement automated solutions, the 
importance of compliance with national standards increases so that all participants may be able to maximize their 
realization of benefits from EDI and EFT. 

IIL NACHA RECORD FORMATS 

The rules and guidelines governing the formats, specifications and exchange of ACH entries are published by NACHA. 
With respect to the data that are contained in the Addenda Records of ACH formats, the NACHA Operating Rules 
stipulate the type of data that may be exchanged as well as which standards and formats are permitted, but the structure 
of me data contents is managed outside of me NACHA rules. 

For example, the NACHA Operating Rules permit the exchange of NACHA-endorsed banking conventions within the 
Addenda Record of the CCD+ format, but groups such as the Bankers EDI Council develop and maintain these banking 
conventions. Also, the rules permit the exchange of certain EDI messages or transaction sets (e.g., 820 Payment 
Order/Remittance Advice) within the Addenda Records of the CTX format and X12 syntax-based data segments within 
the Addenda Records of the CCD+ and PPD+ formats, but those standards are developed and maintained by other 
standards development organizations, such as ASC XI 2 and UN/EDIFACT. 

The following record formats are used to convey entries through the ACH Network: 

> File Header Record 

• Company/Batch Header Record 

'■•. Entry Detail Record 

■;• Addenda Record 

; •. Company/Batch Control Record 

:' • File Control Record 

An ACH file is enveloped by one File Header Record and one File Control Record, which serve to facilitate transmission, 
identification and balancing of the file. A file may be comprised of one or more batches, which are denoted by the 
Company/Batch Header Record and Company/Batch Control Record. These records carry information specific to all 
of the Entry Detail Records contained within that batch. A batch may contain one or more Entry Detail Records that 
share certain aspects as explained in the NACHA Operating Rules. The Entry Detail Record is the record that constitutes 
the payment order and is used within the banking system to execute EFT and settlement. An Addenda Record is used 
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to supply additional information related to the payment issued in the Entry Detail Record; Each Addenda Record 
includes an 80 position Payment Related Information Field within which this remittance detail is transmitted. 

The CCD and CTX payment formats are used within the ACH Network to conduct the transfer of funds between business 
or government entities. To transmit data with payments, Addenda Records are used in conjunction with the payment 
formats . Under the NA CHA Operating Rules, a CCD format may be accompanied by only one Addenda Record, which 
may carry X 1 2 data segments or elements or NACHA-endorsed banking conventions. A CCD entry accompanied by 
an Addenda Record is referred to as a CCD+. The CTX format allows for the provision of 9,999 Addenda Records, 
which may be used to carry certain X12 transaction sets or U^ 

The NACHA record formats for CCD+ entries flow in the following order: 

File Header Record 

Company/Batch Header Record 
Entry Detail Record 

Addenda Record ( 1 addenda with 80 byte Payment Related Information Field) 
Entry Detail Record . 

Addenda Record (1 addenda with 80 byte Payment Related Information Field) 
Entry Detail Record 

Addenda Record (1 addenda with 80 byte Payment Related Information Field) 
Entry Detail Record 

Addenda Record (1 addenda with 80 byte Payment Related Information Field) 
Company/Batch Control Record 
File Control Record 

Following are the layouts for the NACHA Entry Detail and Addenda Records used with the CCD+ format. To obtain 
a full explanation of the rules, specifications and formats for the ACH Network, refer to the NA CHA Operating Rules, 
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Contents 


,'■ . *6' . ■ . ■ 


Numeric 


TTTTAAAA 


Numeric 


Alphameric 


$$$$$$$$11 


Alphameric 


Alphameric 


Alphameric 


Numeric 


Numeric 


Length 


'. .'. i ■ ■ : 


. 2 '■'.;■' 


'■''■' 8 : 


1 


17 


10 


. ■ 15 ■' 


. 22 


'■'.'.■ . 2 ''■■.■ 


;■'■.'■■ J '.■' 


15 


Position 


01-01 


02-03 


04-11 


12-12 


13-29 


30-39 


■■'■'■: 40-54 ■ 


55-76 ■■■': 


■.■:'■■ 77-78 


79-79 :.'■■ 


80-94 



CCD ADDENDA RECORD 



FIELD 


\ '■'■■ 


2 


;'.■■.. .3 ■ . 


.-.■■■;■ 4 ■ ■ 


■ ■ ■' 5 '. 


DATA 

ELEMENT 

NAME 


RECORD 
TYPE CODE 


ADDENDA 
TYPE CODE 


PAYMENT RELATED 
INFORMATION 


ADDENDA 
SEQUENCE NUMBER 


ENTRY DETAIL 
SEQUENCE NUMBER 


Field 

Inclusion 

Requirement 


■■..'.. M 


M 


■' o ;■'.'.-. ■ 


.'.M.'--. 


'■■■■'.■.;. M. : .'.-.'■.■.■'.' 


Contents 


.'7' . . 


■ '05* .... 


Alphameric 


Numeric 


Numeric 


Length 


.'■.■'■.■ 1 ■.'■'■'■'■■■ 


'.'■■:■' 2 


'■.■'■'■■■'■'■'■' so . : : . . 


':'■.'■'.'.'■'.■ 4 : '■'■.'.'■.■ 


1 ■ ■ . 


Position 


01-01 


02-03 


04-83 


: ■ .84-87 ■'.■:.-.:'■. 


■'■-. 88-94 ... . 
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IV. TAX PAYMENT (TXP) BANKING CONVENTION SPECIFICATIONS 

Datafonmttedm^^^ 

Related Information Field of the single Addenda Record comprising the CCD+ format. This convention _is reierreo ^o 

elements: ■'■ : - 

• Segment Identifier > 

• Tax Identification Number (Taxpayer Identification) 
V Tax Payment Type Code (Tax Type Code) 

• Date (Tax Period End Date) 

• Tax Information ID Number (Amount Type) 

• Tax Amount 

• Tax Information ID Number (Amount Type) 

• Tax Amount 

• Tax Information ID Number (Amount Type) 

• Tax Amount 

» Taxpayer Verification 

Each of these fields is referred to as a data element, wWch is the smal^ 

element is referred to by two names. One may be its official, generic name assigned under X12 standards and the secona 

a qualifier, a value, or text. A data element has three primary attributes - length, field requirement, and type. 

Fach data element is identified by an element identifier used for reference (e.g., TXP01 . Taxpayer Identification 

bmmber TXP02° Tax Payment Type Code, etc.) and each element has a specific position wuhin the record (segment). 

SSuS^conSn^ 

and the last data element is immediately followed by a terminator to indicate the end of the ^data ^™^ l ™\f£ 

Network, banking conventions employ an asterisk (<*') as to data element separator and a backslash ( \ ) as the 

terminator. A data segment or convention always begins with the Segment Identifier (e.g., TXP). 

Thefollowingisane X ampleoffoeTa X PayTnent(TXP)BankingCo 
field of the Addenda Record: 

TXP*tax identification number*tax payment type code*date*tax information ID 
number*tax amount*tax information ID number*taxamount*tax information ID 
number*tax amount*taxpayer verificationV 

Note the use of the asterisk ('*') and backslash ('V). 

Data elements in a convention or data -^^^^T^^ot^^: Da ^^^^Sa^sk 
as defined by the standard may be omitted. The omission of an optional element is noted by the placement of an asterisk 
in the place of that element. For example, 

TXP*tax identification number*tax payment type code*date*tax information ID 
number*tax amount*****taxpayer verification\ 

Also if an optional data element is the last data element in the convention and that field is not being used, the preceding 
aSsk ris replaced by the backslash. For example, if the Taxpayer Verification is omitted from the convention, as is 
the case for Federal tax payments, it would look like this: 

TXP*tax identification number*tax payment type code*date*tax information ID 
number*tax amount*tax information ID number*tax amount*tax information 11> 

number*tax amountV 

Following are the Tax Payment (TXP) Banking Convention implementation specifications for state and Federal tax 
payments In both cases, the taxing authorities are using the same field constructs; however, the data element or fed 
Srmayvary. Asindi atedprevi^ the CCD + conveys a single Addenda Record c^onsisting of an 80 po^ 
w2 which payment related information is mapped. In the Federal Government's .mplementation of the TXP 
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convention for EFTPS itdoes not use the Taxpayer Verification (TXP10) By doing so, it is able to accommodate 
longer code values m the Amount Type (Tax Information ffi 

stay within the ,80 byte limit. The use of the separator (<*') between data elements dlows^ EDI tianSs to 
programmatically identify the end of one field and the beginning of the next. translators to 

According toEDI standards, a data element has a minimum and maximum length, within which boundaries the data must 

s3ards?f ; n data d r e ? s ri ha i e a Iogical size from which «* <& <« «m5?dSSrS£S£ 

t«?^i/t t vS" g K mg auth ° rit ^ es > ad °Pt them ^ accordance with the syntax rules, but have the ability to implement 4SS 

nnE>?f T # (eg -' teX Payment P rocessi °g)- The data element minimum and m^xiZnknS S 

^^^*£JZ? ^^^ by thCSe taX ^ Unties, which comply within Z rSges 2 

The Tax Payment (TXP) Banking Convention can accommodate up to three payment amounts the sum of which m,Kt 
published. If more than three amount derations are needed to report subcategories, i^ 



Tax Payment (TXP) Banking Convention: State Implementation 



Data Element Reference Designator & Name 



TXP01 



TXP02 



TXP03 



TXP04 



TXP05 



TXP06 



TXP07 



TXP08 



TXP09 



TXP10 



Segment Identifier 



Taxpayer Identification Number 



Tax Payment Type Code 



Tax Period End Date 



Amount Type (Tax Information ID Number) 



Tax Amount 



Amount Type (Tax Information ID Number) 



Tax Amount 



Amount Type (Tax Information ID Number) 



Tax Amount 



Taxpayer Verification 



Content 



Attributes 



'TXP' 



xxxxxxxxxxxxxxx 



xxxxx 



YYMMDD 



X 



$$$$$$$$cc 



X 



$$$$$$$$cc 



X 



i$> i4> g> ij) 4) i]> ij> ij) ' 



cc 



xxxxxx 



M 



M 



M 



M 



M 



AN 



ID 



DT 



ID 



M 



O 



C 



O 



O 



N2 



ID 



N2 



ID 



N2 



AN 



1/15 



1/5 



6/6 



1/1 



1/10 



1/1 



1/10 



1/1 



1/10 



1/6 
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Tax Payment (TXP) Banking Convention: Federal (EFTPS) Implementation 



Data Element Reference Designator & Name 


Content 


Attributes 


';!:'.'' 


2 


3 




Segment Identifier 


\'TXP.\'^ 


M 






TXPOl 


Taxpayer Identification Number 


XXXXXXXXX 


M 


AN 


9/9 


TXP02 


Tax Payment Type Code 


XXXXX 


M 


ID 


1/5 


TXP03 


Tax Period End Date 


YYMMDD 


M 


DT 


6/6 


TXP04 


Amount Type (Tax Information ID Number) 


XXXXX 


M 


ID 


1/5 


TXP05 


Tax Amount 


3> g) 4> 4> 4) J) J) y) C C 


M 


N2 


1/10 


TXP06 


Amount Type (Tax Information ID Number) 


XXXXX 





ID 


1/3 


TXP07 


Tax Amount 


j> j> j> j> 4) j) j> ij) c c 


C 


N2 


1/10 


TXP08 


Amount Type (Tax Information ID Number) 


XXXXX 





ID 


1/3 


TXP09 


Tax Amount 


j)^ 4) 4)4)^4) u)CC 


G 


N2 


1/10 


TXP 10 


Taxpayer Verification 


(Not used). 



The column headings used on the charts are as follows: 

h Data Element Reference Designator & Name - identify the data element 
b Content - defines the data element 
b Attributes - are defined as follows 

1 . Field Requirement - The first column of the attributes is the field requirement for that data element. An 'M' 
denotes a mandatory element, an 'O' denotes an optional element, and a 6 C' denotes a conditional element -- 
one for which the use is dependent on the presence of another 

2. Data Type - The second column of the attributes specifies the field data type. 

'AN' denotes a string type data element Contents of string data elements are a sequence of letters, digits, spaces 
and/or special characters (with the exception of the asterisk arid backslash). The contents must be left-Justified. 
Trailing spaces should be suppressed unless they are necessary to satisfy a mirrirnum length requirement. 

'DTV denotes a date type data element. Format for the date is YYMMDD. YY is the last two digits of the year 
(00-99), MM is the numeric value of the month (1-12), and DD is the numeric value of the day (1-31). 

'ID' denotes an identifier data element from a pre-defined list of values. 

'N2' denotes a numeric type data element with two decirrml places to the right of a fixed, implied decimal point. 
The decimal point is not transmitted. For example, the amount $5000.00 would appear as *500000*. It is 
intended that this number will always be positive for the Tax Payment (TXP) Banking Convention when used 
in conjunction with an ACH credit. 

3 Length - The third column of the attributes signifies the minimum/rmximumuse of an element. This specifies 

the minimum and maxirnum length of a particular field. For example, 1/6 indicates that this data element must 
be at least one character, but not more than six. 
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■V. DATA ELEMENT- DEFINITIONS ;;■ ... 

TXP01 Tax Identiflcation Number (Taxpayer Identification) 

The Tax Identification Number contains the taxpayer's identification number as assigned by the taxing authority 
This is the nine-digit Employer Identification Number (EIN) for Federal tax payments. 

TXP02 Tax Payment Type Code (Tax Type Code) 

The Tax Payment Type Code is used to identify the type of tax being paid. Code values for state tax payments 
are maintained by the Federation of Tax Administrators (FTA) and Federal codes are maintained by the Internal 
Revenue Service (IRS). 

TXP03 Date (Tax Period End Date) 

The Date is used to indicate the end date for the tax period for which me payrnent is being made. The tax due 
date is information that can be derived from knowing which tax is being paid and what period is being covered 
by the payment. For Federal tax payments, the tax payer supplies only MMYY while the convention requires 
YYMMDD. Always use '01' for the day of the month for EFTPS. This is the tax period ending of the IRS 
Return for which the liability is being paid in YYMMDD format. 

TXP04 Tax Information ID Number (Amount Type) 

The Tax Information ID Number is used to identify the type of amount that immediately follows. The code 
values for this data element for state tax payments, which include 'T' for Tax, T for interest, T' for Penalty, 
'S' for State, 'L' for Local, and 'C for City, are maintained by the Federation of Tax Administrators (FTA)' 
Federal codes are maintained by the Internal Revenue Service (IRS). For EFTPS, this data element is used for 
tax breakdown by subcategory (for 941 or CT-1) or IRS Number (for 720 or 720M). For all other Federal tax 
types, repeat the Tax Payment Type Code from TXP02. 

TXP05 ■'.- TaxAmount 

The Tax Amount represents the amount of tax liability owed and/or paid. This is the only amount value that is 
required. If no subsequent amounts are reported in data elements TXP07 and TXP09, the amount value reported 
in TXP05 must equal the amount value contained in Field 6 of the CCD Entry Detail Record. The amount should 
always include cents ($$$$$$$$cc). 

TXP06 Tax Information ID Number (Amount Type) 

The Tax Information ID Number is used to identify the type of amount that immediately follows. The code 
values for this data element for state tax payments, which include T' for Tax, T for interest, 'P' for Penalty, 
'S' for State, 'L' for Local, and ,'C for City, are maintained by the Federation of Tax Administrators (FTA)! 
Federal codes are maintained by the Internal Revenue Service (IRS). For EFTPS, this data element is used for 
tax breakdown by subcategory (for 94 1 or CT-1 ) or IRS Number (for 720 or 720M), if applicable. This data 
element is optional, but if it is used TXP07 is required. 

■'■' TXP07 ;.'■■;';■;.■■ . : ^; Tax Amount; ^ 

The Tax Amount represents the amount of tax liability owed and/or paid. This amount value is optional, but 
must be used if TXP06 is present. If no subsequent amount is reported in data element TXP09, the total amount 
value reported in the convention (TXP05 + TXP07) must equal the amount value contained in Field 6 of the 
CCD Entry Detail Record. The amount should always include cents ($$$$$$$$cc). 

TXP08 Tax Information ID Number 

The Tax Information ID Number is used to identify the type of amount that immediately follows. The code 
values for this data element for state tax payments, which include -T' for Tax, T for interest, 'F for Penalty, 
'S' for State, 'L' for Local, and 'C for City, are maintained by the Federation of Tax Administrators (FTA)! 
Federal codes are maintained by the Internal Revenue Service (IRS). For EFTPS, this data element is used for 
tax breakdown by subcategory (for 941 or CT-1) or IRS Number (for 720 or 720M), if applicable. This data 
element if optional. If it is used, TXP09 is required. 
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TXP09 TaxAmount 

The Tax Amount represents the amount of tax liability owed and/or paid. This amount value is optional but is 
required if TXP08 is used. The total amount value reported in the convention (TXP05 + TXP07 + 1 XVW) must 
equal the amount value contained in Field 6 of the CCD Entry Detail Record. The amount should always include 
cents ($$$$$$$$cc). 

TXP10 Taxpayer Verification 

The Taxpayer Verification is an optional data element that rmy be used by the receiver to verity ^ 
identity. TXP 10 is not used for Federal tax payments in the EFTPS program. 

VI. EXAMPLES 

The following examples are provided to iUustrate me irnplementation of the T 

and are not intended to depict all cases nor those that apply to all tax payments made for a specific tax type.Tleter to 
the Federation of Tax Administrators and Internal Revenue Service for tax code values for state and Federal tax 
payments, respectively. 

■ 1. State Implementation Usine All Data Elements 

TXP*123456789*6^^ 

Tax Identification Number 123456789 

Tax Payment Type Code 606 (Sales & Use Tax) 

(Tax Period End) Date March31,1996 

TaxAmount $1000.00(T) 

Tax (Penalty) Amount $120.00(P) 

Tax (Interest) Amount $45.67(1) 

Taxpayer Verification SML2A 

2. State Implementation Using One Tax Amount (No Pe nalty or Interest) 
TXP*12345678934*526*960930*T*100000****SML2A\ 

Tax Identification Number 12345678934 

Tax Payment Type Code 526 (Withholding Tax) 

(Tax Period End) Date September 30, 1996 

TaxAmount $1000.00(T) 

Taxpayer Verification SML2A 

3. Federal (EFTPSVImplementation, Employer's Tax 
TXP*123456789*94105*960301*l*10000*2*5000*3n5000 

Tax Identification Number 123456789 

Tax Payment Type Code 941 (941 - 94105, 94107 or 94104) 

(Tax Period End) Date March 1 , 1 996 (9603 = 960301) 

TaxAmount $100.00 (1) Social Security 

TaxAmount $50.00 (2) Medicare 

Tax Amount $150.00 (3) Withholding 

4. Federal (EFTPS) Implementation. Railroad Retirement & Unemploym ent Return 
TXP*123456789*10007*961201*1*10000*2*5000*3*15000\ 

Tax Identification Number 123456789 

Tax Payment Type Code 10007 (CT1 - 10005 or 10007) 

(Tax Period End) Date December 1, 1996 (9612 = 961201) 

TaxAmount $100.00 (1) FICA 
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TaxAmount $50.00 (2) Industry 

Tax Amount $ 150.00 (3) Supplemental 

5 - Federal f EFTPS) Implementation. Excise Tax or Monthly Excise Tax 

TXP*123456789*72005*961201*i4*10000*16*5000*20*15000\ 

Tax Identification Number 123456789 

Tax Payment Type Code 72005 (720 - 72005 or 72007; 720M = 07207) 

(Tax Period End) Date December 1, 1996 (9612 -961201) 

TaxAmount $100.00 (14) IRS Number 

TaxAmount $50.00 (16) IRS Number 

TaxAmount $150.00 (20) IRS Number 

6. Federal iEFTPS) I mplementation; Employer's Unemployment Tax fNo Subcategories) 

TXP*123456789*09405*961201*09405*30000\ 

Tax Identification Number 123456789 

Tax Payment Type Code 09405 (940 = 09405, 09407 or 09404) 

(Tax Period End) Date December 1, 1996 (9612 = 961201) 

TaxAmount $300.00 (Amount Type -TXP02; 09405) 

VII .SOURCES OF INFORMATION 

The following organizations serve as valuable sources of information on EDI, EFT and/or electronic tax payments: 

703/561-1100 National Automated Clearing House Association (NACHA) 

703/548-7005 Data Interchange Standards Association, Inc. (DISA) 

202/624-5890 ...'■..-. Federation of Tax Administrators (FTA) 
202/874-6560 Financial Management Service (FMS) 

202/659-8111 Independent Bankers Association of America (IBAA) 

301/907-2862 Treasury Management Association (TMA) 

VIIL EFTPS FINANCIAL AGENT 

The Financial Agent contracted by the U.S. Treasury for EFTPS is Bank of America (formerly NationsBank) A 
financial institution may be requested to initiate ACH credit payments to both Routing Numbers, as business customers 
may be enrolled with either Treasury Financial Agent. 

Bank of America 
Routing Number: 061036000 

Account Number: 23401009 

Taxpayer Enrollment/Helpline: 1(800)555-4477 

Financial Institution Helpline: 1(800)605-9876 

IX. IRS TAX FORM NUMBERS (ACH CREDIT) 

The IRS Tax Form Numbers Table provides the ACH Credit Tax Form Code Number that should be used when making 
your tax payment via the ACH Credit Remittance Method. The five-digit ACH Credit Tax Form Code Number is to be 
used for your tax type on the TXP addenda. It is required by IRS in order to process your payment correctly. The last 
two digits indicate the type of tax you are reporting under the tax number. For example: If you are reporting a Form 
940 Federal Tax Deposit, the conversion code is 09405. If you are reporting a Form 940 Payment Due on a Return or 
an IRS Notice, the conversion code is 09407. (See table on following page.) 
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Important - Use the following tax form code numbers when making a Federal Tax Deposit (FTD) via ACH 



Credit: 




720- 


- 72005 


940- 


•09405 


941 


-94105 


943 


- 09435 



945-09455 1041-10416 

990C- 99026 1120-11206 

990PF - 99036 CT' 1 ' 1 0005 

990T - 99046 1042-1 0425 
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Valid IRS Tax Types and Subcategories in EFTPS ^ e 



next page for Tax Type Suffixes) 



Tax Form | 

Number 1 'Tax Description 




11-C 
706GS(D) 

706GS(T) 
720 
730 

MWmM 

940 
941 

943 

990 
99DBL 

990C 
990PF 
990T 
1041 
1041 A 

1065 
1066 
1120 
1120DISC 
2290 
2438 
3520 
4720 

5227 
5811 
6069 
8038 
8404 
8612 

8613 

8697 

8725 
8752 
8804 
8805 
8813 
8831 
CT-1 



Special Tax Return and Application for Registry-Wagering 

■GenerationrSkippthg Transfer Tax -for Distribution '■.■'■ ■ ' ," . "; ■ 

Generation-Skipping Transfer Tax tor Terminations 

Quarterly; Excise Tax [see sub^goryJistlngqn page 13} 

Tax on Wagering 

Return by Transferor of Property to Foreign Corporation 

Estates Trust or Partnership. , -■ . ■ " ■■ ■ , :■['.)■■ ■".';:■ ,; : ■ ■■ ,-.; ' . " 

Employer's Annual Unemployment Tax Return Federal Tax Deposit 
Employer's Quarterly Tax ; Return:{aiS Form 94T series) ; 
. Fetieraltfax Deposit (see 'subcategory listinglon page 16) 
Employer's Annual Tax for Agricultural 
Employees Federal Tax Deposit 
Withheld Federal Income fax Federal Tax .Deposit 
Organization Exempt income Tax 

ioforrnatioh and Jn|tjal Excise/iaxVReturri 

tor Black Lung Benefit: Trust and Qertain Related Persons 
Exempt Cooperative Association Income Tax Return 
Return of Private. FouhdatipjiTax^Federa! Tax Deposit 
Exempt Organization Business Income Tax Return 
: Fiduciary income Tax .Return ■ .^ '"",.. ';^\. 
US Information Return - \ 
Trust Accumulation of Charitable Amounts 
Ahriua! Withhbiding Tax ; ;Return for 
Source Income of Foreign Persons 
Partnership Return of Income 
Real Estate Mortgage TnvestrnentConduif Income Tax 
US Corporation Income Tax Federal Tax Deposit 
. Domestic.lnternational Sales. Corporation Return 
Heavy Vehicle Use Tax Return 

Regulated Investment Company -Undistributed Capital Gains 
Information Return - Creation/Transfer to Foreign Trusts 
Return of Certain Excise Taxes on .Charities and Other Persons 
Under Chapter 41 ;;&4M the IRC 
Split-Interest Trust Information Return 
Examination Return Preparer Case Closing Document 
Return of Excess Tax on Excise Contribution to Black Lung Trust 
information Return forTax h Exempt Private Activity Bond Issue 
Interest Charge on DISC-Refated Deferred Tax Liability 
Return of Excise Tax on Undistributed Income of 
of Real Estate Investment Companies 

Return of Excise Tax on Undistributed income 

of Regulated Investment Companies : : 

interest Under the Look-Back:Method.. 
for Completed Long-Term Contracts 

Excise Tax on Greenmaii 

Required Payment or Refund Under Section 7519 

Annual Return Partnership Withholding Tax (Section 1446} 

Foreign Partners information Statement of Section 1446 Withholding Tax 

Partnership Withholding Tax Payment '""-■" 

Excise Taxesonfxcess Incfusionsot mm Residual Interest v ■; 

Railroad Retirement Tax and Unemployment Return 
(see subcategory listing below) 



■ r' : - : --■/■' ■■:;.'■■' -v- " ^:. v |. '..-:■■■".. {■.;;v : .Valid. Suffixes; 
J Tax Ty pe Prefix 1 (Last tfigit of tax type) 
I ;ff ifSt4 digits) > ';::|;S;'|see:U'||enfl;pri;page J 16)f. : .i 



CT ' 2 |i Employee Representatives Railroad: Retirement 



0111 | 3,4, 7,8,9,8 

>. 7062 JJV-'J ,;"■:::'. :."^4;.7,,a;-9 r B-v:y 

7063 ■■■■J .3.4,7,8,9,B 

0? 30 I : 3 f 4, 7,8, 9B 

0940 I' ' a 4, 5.7,8,9,6 

0943 I 3, 4, 5, 7. 8, 9, B 

,/-0945 ■ ' ;1 0,3,4; 5; 7, 8; 9, B 
0990 I 3, 4, 7, 8, 9, B " 

■.■9902 1 2, 3, 4, 6, 7, 8, 9, B 

■;--9903' : -;" ! V;-. |- v ; 3;4 i 6 r 7;8 1 9,B^ 
9904 ■■■■■! 2, 3, A, 6, 7, 8, 9, B 

104i\ i^|- '"X 2;3 t i &6,7; : ft^l^.^'.} 
1411 J 3,4,7,8,9,8 . 

: ' ; .,1042;.^ : - ■|:X';^'-3r4v5;'.7; ,; 8;?i- i, B : /-!- 

1065 I ■2,3,4,6.7,8,9,6 : 

■ 1066 "■■ 1 ■-..;; .;,:3 ; 4,7,8,9;B ■.: 
1120 | 0,2, 3, 4,6.7,8,9,8 

112| 4 :'■.' I, ;■".'■■ 3,4,7; 8.9, b 

22 9° j 3,4,7,8,9,8 

■: V2438^. V::; J.. ;: w 3/4,7; 8,9, 8 
352 ° I ' 3, 4, 7, 8, 9, B 

■ : .^ 2 '0.. './'I:"'' :.' ■■.3/4 1 7.fil:9'.-B.- 

5227 j 3,4,7,8,9,6 

■ 581t r ;-.' , ; jy; : 3,4,7,8, 9/0 :,.'■ 
6069 I 3,4,7,8,9,8 

■ ■8038.:' ;./| -JO- ■■ ■3 t 4/7, 8i;9,;B : . ■■;■■ 
84 4 I 3,4,7,8,9,8 " 
mZ ■ ';,i|;V. : . 3;4,7, 8,9,8 ■: 

8613 1 3,4,7,8.9, B 

8697 y. ■| '.:'_. ■ 3,4, 7, 8, 9,8 ■" 

8725 I :■ 3,4,7,8,9,8 

■ 8752 ■ - |. "";. ■ 3,4,7,8,9,8 ' 
8804 1 3,4,7,8,9,6 
8804 J-- 3, 4, 7, 8, 9, 6 
8804 | 3,4,7,8,9,6 ■'■ 
8612 ■■'■ -I ..' .- 3,4- 7, 8, 9, B 
1000 I 3, 4, 5, 7, 8, 9 : B 

0002 y ■§-■'■■. ' 2, 4,7, 8,9, 6 



Ending Dates 



: oi~i2 

||ISiiB.|S;;; 

12 
03, 06, 09, 12 

01-12 

12 

|o|)3li9gi|l 

12 

(01-12) 
(01-12) 

(01-12) 

■■>'";■■ ■■'■(oi : i'2)- >■■■':■■ 

(01-12) 
(01-12) 

(01-12) 

mffmBMm 

.■'::;■ (01-12) ;; 

01-12: 

.(01-12) 

. .(01-12) . 

01-12 

12 
; 01-12 

(01-12) 

12 

01-12 
01-12 

01-12 ;'.■'.".'■ 

01-12 

01-12 

12 
01-12 : 
01-12 
01-12 
01-12 

12 

03,06,09, 12 
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Legend for Tax Type Suffixes (Last digit of tax type) 

Suffix Type 

Amended 

Extension ; : 

Designated Payment of Fees of Collection Costs 



Advance Payment of Determined Deficiency 

Deposit 

Estimated 

Subsequent/With Return 

Designated Payment of Interest 

Designated Payment of Penalty 

Cash Bond Payment 



Description 

Tax payment made as a result of a balance due on an amended tax return. 

Tax payment due on a request for extension of time to file. 

Payment of user fees (for example, photocopies, installment agreements) 

or collections costs. 

Payment made on an IRS examination or audit. 

Federal tax deposit. 

Tax payment made based on estimated liability. 

Tax payment due on a return or IRS notice. 

Payment of an Interest amount due. 

Payment of a penalty amount due. . 

Payment made to stop interest on examination deficiency. 



Subcategory Codes Associated with Form Number 941 

/. SOCS— Social Security 'Amount ' . 

MEDi-Medieare Amount 
WITH-Withlioldin- Amount 



Subcategory Codes Associated with Form Number CT-1 

RRTI-RRB Tier I (FICA Equivalent) 
RRT2-RRB Tier II (Industry Portion) 
RRT3-RRB Tier III (Supplemental Annuity) 



#D 



PLEASE NOTE: It is normal procedure lor IRS subcategory codes to be added or deleted based 
on legislation. You may - Gphtact iB'isi'-i. p.r .uftda'tes'vtd : -lKis 
Tax subcategory amounts must balance to the total tax amount, or only the tax amount will be reported. 



720 Quarterly Federal Excise Tax IRS Subcategory Codes 

The following chart is a reference list of various IRS Numbers. 



IRS 
Number 



Description 



IRS 

Number Description 



IRS 
Number Description 



IRS 
Number Description 



14 


Gasoline for use in non- : " : 


31 


Obligations not in registered form 


60 


Diesel fuel 


77 


LUST tax on aviation fuel 




commercial aviation 


33 


Truck, trailer, and semitrailer chassis 


; 61 


Liquefied Petroleum Gas (LPG) 




(other than gasoline) 


■;16 


Imported petroleum products ■ '■•; 
Superfjhd tax 


35 


and bodies, and tractors 
Kerosene 


62 


(a) Gasoline, tax on removal 
attemiina! rack ' ; : 


78 


Diesel fuel for use in certain intercity 
buses 


;i7 '■ 


imported chenncai substances 




{effective July (,1998) 




(b) Gasoline, tax on taxable, events, 
other than removal at terminal rack 


79 


Other Special Fuels 


18 


Oil spill-imported (repealed) ' 


36 


Coal-Underground mined 






85 


Diesel floor stock 


19 


Imported products containing ODGs 




@ 50/ $110 per ton 


64 


Inland waterways fuel use tax :, 


86 


Other alcohol fuels floor stock 


20 


Ozone-depleting chemicals 
(floor stocks) . 


37 


Coal-Underground mined 
@ 4.4% [imitation of ton price 


65 

66 : 


Gasoline floor stock 
Highway-type tires ; 


8? 


'Aviation fuel (other than gasoline') 
floor stock. 10-1-93 


21 
22 


Oil. spill-domestic (repealed). ;■,■;..;.■ 

Toli telephone, seivice-.- 

teletype-writer exchange service.; 
and locaf telephone service 


38 
39 


Coal-Surface mined 
#50/ $1.10 per ton 

Coal-Surface mined 

® 4.4% limitation of ton price 


67 

.';' ;69:, 
70 


'Gasohoi floor stock' 
Aviation fuel (other than gasoline) 
Diesei floor, stock 


88 
89 


Diesel' fuel, based on January 1,1994 
inventory floor stock 

Vaccines Numbers 81-84 
floor stock. 8-08-93 


26 


Transportation of person by air , 


40 


Gas guzzler tax 


71 


Diesel fuel for use in trains 


92 


Passenger vehicles 


27 


Use of international air travel 


41 


Spoil fishing equipment 


72 


Gas to make gasohoi floor stock 


95 


Aviation Fuel (other than gasoline) 




facilities 


42 


Electric outboard motors 


■: 73 


Gasoline sold for gasohoi production 




floor stock, 3-17-97 


23 


Transportation of property by air 




and sonar devices 




containing at least .7.7% alcohol 
but less than 10% alcohol 


96 


Aviation Gasoline (floor stock} 


29 
30 


Transportation by water 

Life insurance, sickness and accident 


44 
51 


Bows 

Alcohol sold as but not used in fuel 


74 


Gasoline sold for gasohoi ',■ ■ 
production containing at least 5.7% 


98 
97 


Ozone-depleting chemicals (ODCs) 
Vaccines 




: policies, and annuity contracts 


53 


Domestic petroleum Supe'rfund tax 




alcohol but less than 7.7% alcohol 


101 


Compressed natural gas (tax rate per 




Foreign insurance Taxes 


54 


Chemicals 


75 


Gasohoi containing at least 




thousand cubic feet) 




Policies issued by foreign insurers 
Casualty insurance and indemnity 
bonds 


58 


Gasoline sold for gasohoi production 
containing at least 10% alcohol 


: 76 


7. 7%-9.9% alcohol 

Gasohoi containing at least 
5 7%-7 6% alcohol 


102 
103 


Arrow-Component Parts 
Kerosene (Floor Stock) 




Reinsurance 


59 


Gasohoi containing at least 
10% alcohol 








(effective July 1,1998) 


Note. 


Contact IRS at 1-800-829-1040 if a particular number is 


not listed. 
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AUTOMATED CLEARING HOUSE 

:'(ACH)^ 

DEPARTMENT OF THE TREASURY 
Fiscal Service 

31G.F.R,Part210 

Section Contents 



Subpart ^—General 

§ 210.4 Authorizations and revocations of authorizations. 

§ 210.5 Account requirements for Federal payments. 

§210.6 Agencies. 

§210.7 Federal Reserve Banks. 

§ 210.8 Financial institutions. 

Subpart B— Reclamation of Benefit Payments 

§ 210.9 Parties to the reclamation. 

§ 210.10 RDFI liability. 

§ 210.1 1 Limited liability. 

§ 210. 12 RDFFs rights of recovery. 

§210.13 Notice to account owners. 

§ 210.14 Erroneous death information. 

Appendix A to Fart 21 0-^Standard Disclosure for 
Point-of-Purchase Conversion— Posted Notice 

Appendix B to Part 210— Standard Disclosure for 
Point-of-Purchase Conversion— Brochure or 
Pamphlet 

Appendix C to Part 210— Standard Disclosure for 
Accounts Receivable Conversion Notice 

Authority: 5 U.S.C. 5525; 12U.S.C. 391; 31 U.S.C. 321, 
3301, 3302, 3321, 3332, 3335, and 3720. 

Source: 64 FR 17487, Apr. 9, 1999, unless otherwise 
noted. 



§ 210.1 Scope; relation to other regulations. 

This part governs all entries and entry data originated or 
received by an agency through the Automated Clearing 
House (ACH) network, except as provided in paragraphs 
(a) and (b) of this section. This part also governs 
reclamations of benefit payments. 



(a) Federal tax payments received by the Federal 
Government through the ACH system that are governed 
by part 203 of this title shall not be subject to any 
provision of this part that is inconsistent with part 203. 

(b) ACH credit or debit entries for the purchase 
of, or payment of principal and interest on, United States 
securities that are governed by part 370 of this title shall 
not be subject to any provision of this part that is 
inconsistent with part 370. 

.'■§ 210.2 Definitions. 

For purposes of this part, the following definitions apply. 
Any term that is not defined in this part shall have the 
meaning set forth in the ACH Rules. 

(a) A CH Rules means the Operating Rules and 
the Operating Guidelines published by NACHA— The 
Electronic Payments Association (NACHA), a national 
association of regional member clearing house 
associations, ACH Operators and participating financial 
institutions located in the United States. 

(b) Actual or constructive knowledge, when used 
in reference to an RDFFs knowledge of the death or legal 
incapacity of a recipient or death of a beneficiary, means 
that the RDFI received information, by whatever means, 
of the death or incapacity and has had a reasonable 
opportunity to act on such information or that the RDFI 
would have learned of the death or incapacity if it had 
followed commercially reasonable business practices. 

(c) ^[ge«cy means any department, agency, or 
instrumentality of the United States Government, or a 
corporation owned or controlled by the Government of the 
United States. The term agency does not include a Federal 
Reserve Bank. 

(d)^ 
with an effective date on or before June 13, 2003, as 
published inParts II, III, and IV of the "2003 ACH Rules: 
A Complete Guide to Rules & Regulations Governing the 
ACH Network," including the supplement thereto 
approved February 27, 2003 and effective June 13, 2003, 
except: 

(1) ACH Rule 1.1 (limiting the 
applicability of the ACH Rules to 
members of an ACH association); 

(2) ACH Rule 1 .2.2 (governing claims for 
compensation); 

(3) ACH Rule 1.2.4; 2.2.1.10; Appendix 
Eight and Appendix Eleven (governing 
the enforcement of the ACH Rules, 
including self-audit requirements); 
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(4) ACH Rules 2.2.1.8; 2.6; and 4.7 
(governing the reclamation of benefit 
payments); 

(5) ACH Rule 8.3 and Appendix Two 
(requiring that a credit entry be 
originated no more than two banking 
days before the settlement date of the 
entry — see definition of "Effective 
Entry Date" in Appendix Two); 

(6) ACH Rule 2.10.2.2 (requiring that 
originating depository financial 
institutions (ODFIs) establish exposure 
limits for Originators of Internet- 
initiated debit entries); and 

(7) ACH Rule 2. 1 1 .3 (requiring reporting 
regarding unauthorized Telephone- 
initiated entries). 

(e) Authorized payment agent means any 
individual or entity that is appointed or otherwise selected 
as a representative payee or fiduciary, under regulations 
of the Social Security Administration, the Department of 
Veterans Affairs, the Railroad Retirement Board, or other 
agency making Federal payments, to act on behalf of an 
individual entitled to a Federal payment. 

(f) Automated Clearing House or A CH means a 
funds transfer system governed by the ACH Rules which 
provides for the interbank clearing of electronic entries for 
participating financial institutions. 

(g) Beneficiary means a natural person other than 
a recipient who is entitled to receive the benefit of all or 
part of a benefit payment. 

(h) Benefit payment is a payment for a Federal 
entitlement program or for an annuity, including, but not 
limited to, payments for Social Security, Supplemental 
Security Income, Black Lung, Civil Service Retirement, 
Railroad Retirement annuity and Railroad Unemployment 
and Sickness benefits, Department of Veterans Affairs 
Compensation and Pension, and Worker's Compensation. 

(i) Federal payment means any payment made by 
an agency. The term includes, but is not limited to: 

(1) Federal wage, salary, and retirement 
payments; 

(2) Vendor and expense reimbursement 
payments; 

(3) Benefit payments; and 

(4) Miscellaneous payments including, but 
not limited to, interagency payments; 
grants; loans; fees; principal, interest, 
and other payments related to United 



States marketable and nonmarketable 
securities; overpayment 
reimbursements; and payments under 
Federal insurance or guarantee 
programs for loans. 

(j)( 1 ) Financial institution means: 

(i) Any insured bank as defined 

in section 3 of the Federal 
Deposit Insurance Act (12 
U.S.C. 1813) or any bank 
which is eligible to apply to 
become an insured bank 
under section 5 of such Act 
(12 U.S.C. 1815); 

(ii) Any mutual savings bank as 

defined in section 3 of the 
Federal Deposit Insurance Act 
(12 U.S.C. 1813) or any bank 
which is eligible to apply to 
become an insured bank 
under section 5 of such Act 
(12 U.S.C 1815); 

(iii) Any savings bank as defined 
in section 3 of the Federal 
Deposit Insurance Act (12 
U.S.C. 1813) or any bank 
which is eligible to apply to 
become an insured bank 
under section 5 of such Act 
(12 U.S.C. 1815); 

(iv) Any insured credit union as 
defined in section 101 of the 
Federal Credit Union Act (12 
U.S.C. 1752) or any credit 
union which is eligible to 
apply to become an insured 
credit union pursuant to 
section 201 of such Act (12 
U.S.C 1781); 

(v) Any savings association as 

defined in section 3 of the 
Federal Deposit Insurance Act 
(12 U.S.C 1813) which is an 
insured depository institution 
as defined in such Act (12 
U.S.C 1811 et seq.) or is 
eligible to apply to become an 
insured depository institution 
under the Federal Deposit 
Insurance Act (12 U.S.C 
1811 eiseq.)\ and 

(vi) Any agency or branch of a 
foreign bank as defined in 
section 1(b) of the 
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International Banking Act, as 
amended (12 U.S.C. 3101). 

(2) In this part, a financial institution may 

be referred to as an Originating 
Depository Financial Institution 
(ODFI) if it transmits entries to its 
ACH Operator for transmittal to a 
Receiving Depository Financial 
Institution (RDFI), or it may be 
referred to as an RDFI if it receives 
entries from its ACH Operator for debit 
or credit to the accounts of its 
customers. 

(k) Government entry means an ACH credit or 
debit entry or entry data originated or received by an 
agency. 

(1) Green Book means the manual issued by the 
Service which provides financial institutions with 
procedures and guidelines for processing Government 
entries. 

(m) Notice of reclamation means notice sent by 
electronic, paper, or other means by the Federal 
Government to an RDFI which identifies the benefit 
payments that should have been returned by the RDFI 
because of the death or legal incapacity of a recipient or 
death of a beneficiary. 

(n) Outstanding total means the sum of all 
benefit payments received by an RDFI from an agency 
after the death or legal incapacity of a recipient or the 
death of a beneficiary, minus any amount returned to, or 
recovered by, the Federal Government. 

(o) Recipient means a natural person, 
corporation, or other public or private entity that is 
authorized to receive a Federal payment from an agency. 

(p) Service means the Financial Management 
Service, Department of the Treasury. 

(q) Treasury means the United States 
Department of the Treasury. 

(r) Treasury Financial Manual m^ 
issued by the Service containing procedures to be 
observed by all agencies and Federal Reserve Banks with 
respect to central accountingj financial reporting, and 
other Federal Government-wide fiscal responsibilities of 
the Treasury. 

[64 FR 17478, Apr. 9, 1 999, as amended at 65 FR 1 8869, 
Apr 7, 2000; 66 FR 10580, Feb. 16, 2001 ; 67 FR 17902, 
Apr. 11, 2002; 68 FR 33829, June 5, 2003] 



§ 210.3 Governing law. 

(a) Federal lawThe rights and obligations of the 
United States and the Federal Reserve Banks with respect 
to all Government entries, and the rights of any per 
recipient against the United States and the Federal 
Reserve Banks in connection with any Government entry, 
are governed by this part, which has the force and effect 
of Federal law. 



Rules. 



(b) Incorporation by reference— applicable A CH 



(1) This part incorporates by reference the 

applicable ACH Rules, including rule 
changes with an effective date on or 
before June 13, 2003, as published in 
Parts II, III, and IV of the "2003 ACH 
Rules: A Co 

Regulations Governing the ACH 
Network," including the supplement 
thereto approved February 27, 2003 
and effective June 13, 2003. The 
Director of the Federal Register 
approves this incorporation by 
reference in accordance with 5 U.S. C. 
552(a) and 1 CFR Part 51. Copies of 
the "2003 ACH Rules" are available 
from NACHA— The Electronic 
Payments Association, 13665 Dulles 
Technology Drive, Suite 300, Herndon, 
Virginia 20171. Copies also are 
available for public inspection or at the 
National Archives and Records 
Administration (NARA). For 
information on the availability of this 
material at NARA, call 202-74 1-6030, 
or go t o : 

http://www.archives.gov/federal_regi 
ster/codejof_federal_regulations/ibr_ 
locations. html, and the Financial 
Man^^^ 

SW., Room 420, Washington, DC 
20227. 

(2) Any amendment to the applicable ACH 

Rules that takes effect after June 13, 
2003, shall not apply to Government 
entries unless the Service expressly 
accepts such amendment by publishing 
notice of acceptance of the amendment 
to this part in the Federal Register. An 
amendment to the ACH Rules that is 
accepted by the Service shall apply to 
Government entries on the effective 
date of the rulemaking specified by the 
Service in the Federal Register notice 
expressly accepting such amendment. 

(c) Application of this part Any person or entity 
that originates or receives a Government entry agrees to 
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be bound by this part and to comply with all instructions 
and procedures issued by the Service under this part, 
including the Treasury Financial Manual and the Green 
Book. The Treasury Financial Manual is available for 
downloading at the Service's web site at 
http://www.frns.treas.gov/ or by calling (202) 874-9940 
or writing the Directives Management Branch, Financial 
Management Service, Department of the Treasury, 3700 
East West Highway, Room 500C, Hyattsville, MD 20782; 
The Green Book is available for downloading at the 
Sex Vic e ' s w e b s i t e at 
http://www.fms.treas.gov/fmsnews.ht^ calling 

(202) 874-6540 or writing the Product Promotion 
Division, Financial Management Service, Department of 
the Treasury, 401 14th Street, SW., Room 309, 
Washington, DC 20227. 

[64 FR 17478, Apr. 9, 1999, as amended at 65 FR 18869, 
Apr. 7, 2000; 66 FR 10580, Feb. 16, 2001; 67 FR 17903, 
Apr. 1 1, 2002; 68 FR 33830, June 5, 2003; 69 FR 18803, 
Apr. 9,2004] 

Subpart A— General 



§ 210.4 Authorizations and revocations of 
authorizations. 

(a) Requirements for authorization. Each debit 
and credit entry subject to this part shall be authorized in 
accordance with the applicable ACH Rules and the 
following additional requirements: 



(1) The agency or the RDFI that accepts 
the recipient's authorization shall verify 
the identity of the recipient and, in the 
case of a written authorization 
requiring the recipient's signature, the 
validity of the recipient's signature. 

(2) Unless authorized in writing, or 
similarly authenticated, by an agency, 
no person or entity shall initiate or 
transmit a debit entry to that agency, 
other than a reversal of a credit entry 
previously sent to the agency. 




(b) Terms of authorizations. By executing an 
authorization for an agency to initiate entries, a recipient 
agrees: 

(1) To the provisions of this part; 

(2) To provide accurate information; 

(3) To verify the recipient's identity to the 
satisfaction of the RDFI or agency, 
whichever has accepted the 
authorization; 

(4) That any new authorization inconsistent 
with a previous authorization shall 



supersede the previous authorization; 

'■:■;'■ and 

(5) That the Federal Government may 

reverse any duplicate or erroneous 
entry or file as provided in §210.6(f) of 
tto 

(c) Termination and revocation of 
authorizations. An authorization shall remain valid until 
it is terminated or revoked by: 

(1) With respect to a recipient ofbenefit 
payments, a change in the recipient's 
ownership of the deposit account as 
reflected in the deposit account 
records, including the removal of the 
name of the recipient, the addition of a 
power of attorney, or any action which 
alters me interest of the recipient; 

(2) The death or legal incapacity of a 
recipient of benefit payments or the 
death of a beneficiary; 

(3) The closing of the recipient's account at 
the RDFI by the recipient or by the 
RDFI. With respect to a recipient of 
benefit payments, if an RDFI closes an 
account to which benefit payments 
currently are being sent, it shall provide 
30 calendar days written notice to the 
recipient prior to closing the account, 
except in cases of fraud; or 

(4) The RDFI's insolvency, closure by any 
state or Federal regulatory authority or 
by corporate action, or the appointment 
of a receiver, conservator, or liquidator 
for the RDFI. In any such event, the 
authorization shall remain valid if a 
successor is named. The Federal 
Government may temporarily transfer 
authorizations to a consenting RDFI. 
The transfer is valid until either a new 
authorization is executed by the 
recipient, or 120 calendar days have 
elapsed since the insolvency, closure, 
or appointment, whichever occurs first. 

§ 21 0.5 Account requirements for Federal payments. 

(a) Notwithstanding ACHRules 2. 1 .2, 4. 1.3, and 
Appendix Two, section 2.2 (listing general ledger and 
loan accounts as permissible transaction codes), an ACH 
credit entry representing a Federal payment other than a 
vendor payment shall be deposited into a deposit account 
at a financial institution. For all payments other than 
vendor payments, the account at the financial institution 
shall be in the name of the recipient, except as provided in 
paragraph (b) of this section. 
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\ ©a): 



(2) 



(3) 



Where an authorized payment agent 
has been selected, the Federal payment 
shall be deposited into an account titled 
in accordance with the regulations 
governing the authorized payment 
agent; 

Where a Federal payment is to be 
deposited into an investment account 
established through a securities broker 
or dealer registered with the Securities 
and Exchange Commission under the 
Securities Exchange Act of 1 934, or an 
investment account established through 
an investment company registered 
under the Investment Company Act of 
1940 or its transfer agent, such 
payment may be deposited into an 
account designated by such broker or 
dealer, investment company, or transfer 
agent. 

The Secretary of the Treasury may 
waive the requirements of paragraph 
(a) of this section in any case or class 
of cases. 



[64FR 17478, Apr. 9,1 999, as amended at 65 FR 18869, 
Apr.7,2000] 

§ 210.6 Agencies. 

Notwithstanding ACH Rules 2.2.3, 2.4.5, 2.5.2, 
4.2, and 7.7.2, agencies shall be subject to the obligations 
and liabilities set forth in this section in connection with 
Government entries. 

(a) Receiving entries. An agency may receive 
ACH debit or credit entries only with the prior written 
authorization of the Service. 

(b)IwM/^/oa recipient An agency will be 
liable to the recipient for any loss sustained by the 
recipient as a result of the agency's failure to originate a 
credit or debit entry in accordance with this part. The 
agency's liability shall be limited to the amount of the 
entry(ies). 

(c) Liability to an originator. An agency will be 
liable to an originator or an ODFI for any loss sustained 
by the originator or ODFI as a result of the agency's 
failure to credit an ACH entry to the agency's account in 
accordance with this part. The agency's liability shall be 
limited to the amount of the entry(ies). 

(d) Liability to an RDFI or ACH association. 
Except as otherwise provided in this part, an agency will 
be liable to an RDFI for losses sustained in processing 
duplicate or erroneous credit and debit entries originated 
by the agency. An agency's liability shall be limited to the 
amount of the entry(ies), and shall be reduced by the 



amount of the loss resulting from the failure of the RDFI 
to exercise due diligence and follow standard commercial 
practices in processing the entry(ies). This section does 
not apply to credits received by an RDFI after the death or 
legal incapacity of a recipient of benefit payments or the 
death of a beneficiary as governed by Subpart B of this 
part. An agency shall not be liable to any ACH 
association. 

(c} Acquittance of the agency. The final crediting 
of the amount of an entry to a recipient's account shall 
constitute full acquittance of the Federal Government. 

(f) Reversals. An agency may reverse any 
duplicate or erroneous entry, and the Federal Government 
may reverse any duplicate or erroneous file. In initiating 
a reversal, an agency shall certify to the Service that me 
reversal complies with applicable law related to the 
recovery of the underlying payment. An agency that 
reverses an entry shall indemnify the RDFI as provided in 
the applicable ACH Rules, but the agency's liability shall 
be limited to the amount of the entry. If the Federal 
Government reverses a file, the Federal Government shall 
indemnify the RDFI as provided in the applicable ACH 
Rules, but the extent of such liability shall be limited to 
the amount of the entries comprising the duplicate or 
erroneous file. Reversals under this section shall comply 
with the time limitations set forth in the applicable ACH 
■ Rules. 

(g) Point-of-purchase debit entries. An agency 
may convert to an ACH debit entry a check drawn on a 
consumer or business account and presented at a point-of- 
purchase. Agencies shall use the Point-of-Purchase (POP) 
Standard Entry Class (SEC) code for entries to consumer 
accounts and the Cash Concentration or Disbursement 
(CCD) SEC code for entries to business accounts. The 
requirements of ACH Rules 2 1.2 and 3 .4 shall be met for 
such an entry if the Receiver presents the check at a 
location where the agency has posted a conspicuous 
notice at the point-of-purchase containing the disclosure 
set forth at appendix A to this part and makes available to 
the Receiver, in a form that the Receiver can retain, the 
disclosure set forth at appendix B to this part. For 
purposes of ACH Rules 3 .1 and 4. 1 . 1 , authorization shall 
consist of a copy of the notice and a copy of the 
Receiver's source document. 

(h) Accounts receivable check conversion. 

( 1 ) Conversion of consumer checks.— An 

agency may originate an Accounts 
Receivable (ARC) entry using a check 
drawn on a consumer account that is 
received via the mail or at a dropbox, 
or that is delivered in person in 
circumstances in which the agency 
cannot contemporaneously image and 
return the check. The notice and 
authorization requirements of ACH 
Rules 2.1.4 and 3.6.1 shall be met for 
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an ARG entry only if an agency has 
provided the Receiver with the 

disclosure set forth at appendix C to 
this part. 

(2) Conversion of business checks. An 

agency may originate an AGH debit 
using a business check that is received 
via the mail or at a dropbox, or that is 
delivered in person in circumstances in 
which the agency cannot 
contemporaneously image and return 
the check. The agency shall use the 
CCD SEC code for such entries, which 
shall be deemed to meet the 
requirements of ACH Rule 2.1.2 if the 
agency has provided the disclosure set 
forth at appendix C to this part. For 
purposes of AGH Rules 3 .10 and 4. 1 . 1 , 
authorization shall 

_ (i) Returned item service fee. An agency may 
originate an ACH debit entry to collect a one-time service 
fee in connection with an ACH debit entry originated 
pursuant to paragraph (g) or (h) of this section that is 
returned due to insufficient funds. An entry originated 
pursuant to this paragraph shall meet the requirements of 
ACH Rules 2. 1 .2 and 3.4 if the agency has complied with 
the disclosure requirements of paragraph (g) or (h), as 
appropriate. For purposes of ACH Rule 3.10 and 4.1.1, 
authorization shall consist of a copy of the notice 
provided under paragraph (g) or (h), as applicable, and a 
copy of the Receiver's source document. 

[64 FR 1 7487, Apr. 9, 1999, as amended at 67 FR 17903, 
Apr. 11, 2002; 69 FR 13189, Mar. 19, 2004] 

§ 210.7 Federal Reserve Banks. 

(a) Fiscal Agents. Each Federal Reserve Bank 
serves as Fiscal Agent of the Treasury in carrying out its 
duties as the Federal Government's ACH Operator under 
this part. As Fiscal Agent, each Federal Reserve Bank 
shall be responsible only to the Treasury and not to any 
other party for any loss resulting from the Federal Reserve 
Bank's action, notwithstanding Section 1 1 .5 and Article 8 
of the ACH Rules. Each Federal Reserve Bank may issue 
operating circulars not inconsistent with this part which 
shall be binding on financial institutions. 

(b) Routing numbers. All routing numbers issued 
by a Federal Reserve Bank to an agency require the prior 
approval of the Service. 

§ 210.8 Financial institutions. 

(a) Status as a Treasury depositary. The 
origination or receipt of an entry subject to this part does 
not render a financial institution a Treasury depositary. A 
financial institution shall not advertise itself as a Treasury 
depositary on such basis. 



■:■:::■■;; r;[.$) Liability. Notwithstanding ACH Rules 2.2.3, 
2.4.5, 2.5.2, 4.2, and 7.7.2, if the Federal Government 
sustains a loss as a result of a financial institution's failure 
to handle an entry in accordance with this part, the 
financial institution shall be liable to the Federal 
Government for the loss, up to the amount of the entry, 
except as otherwise provided in this section. A financial 
institution shall not be liable to any third party for any loss 
or damage resulting directly or indirectly from an agency's 
error or omission in originating an entry. Nothing in this 
section shall affect any obligation or liability of a financial 
institution under Regulation E, 12 CFR part 205, or the 
Electronic Funds Transfer Act, 12 U.S.C. 1693 et seq. 

( 1 ) An ODFI that transmits a debit entry to 

an agency without the prior written or 
similarly authenticated authorization of 
the agency, shall be liable to the 
Federal Government for the amount of 

^^ ^ The 

Service may collect such funds using 
procedures established in the 
applicable ACH Rules or by instructing 
a Federal Reserve Bank to debit the 
ODFI's account at the Federal Reserve 
Bank or the account of its designated 
correspondent. The interest charge 
shall be at a rate equal to the Federal 
funds rate plus two percent, and shall 
be assessed for each calendar day, from 
the day the Treasury General Account 
(TGA) was debited to the day the TGA 
is recredited with the full amount due. 

(2) An RDFI that accepts an authorization 

in violation of §2 1 0.4(a) shall be liable 
to the Federal Government for all 
credits or debits made in reliance on 
the authorization. An RDFI that 
transmits to an agency an authorization 
containing an incorrect account number 
shall be liable to the Federal 
Government for any resulting loss, up 
to the amount of the payment(s) made 
on the basis of the incorrect number. If 
an agency determines, after appropriate 
investigation, that a loss has occurred 
because an RDFI transmitted an 
authorization or notification of change 
containing an incorrect account 
number, the agency may instruct the 
Service to direct a Federal Reserve 
Bank to debit the RDFI's account for 
the amount of the payment(s) made on 
the basis of the incorrect number. The 
agency shall notify the RDFI of the 
results of its investigation and provide 
the RDFI with a reasonable opportunity 
to respond before initiating such a 
debit. 
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final crediting of the correct amount of an entry received 
and processed by the Federal Reserve Bank and posted to 
the TGA shall constitute full acquittance of the ODFI and 
the originator for the amount of the entry. Full acquittance 
shall not occur if the entries do not balance, are 
incomplete, are incorrect, or are incapable of being 
processed. In the case of funds collected by an agency 
through origination of a debit entry, full acquittance shall 
not occur until the underlying payment becomes final. 

(d) Notice of misdirected payment If an RDFI 
becomes aware that an agency has originated an ACH 
credit entry to an account that is not owned by the payee 
whose name appears in me ACH payment information, the 
RDFI shall promptly notify the agency. An RDFI that 
originates a Notification of Change (NOC) entry with the 
correct account and/or Routing and Transit Number 
information, or returns the original ACH credit entry to 
the agency with an appropriate return reason code, shall 
be deemed to have satisfied this requirement 

[64 FR 17487, Apr. 9, 1999, as amended at 69 FR 13 1 89, 
Mar. 19,2004] 

Subpart B— Reclamation of Benefit Payments 



§ 210.9 Parties to the reclamation. 

(a) Agreement of RDFI An RDFI's acceptance 
of a benefit payment pursuant to this part shall constitute 
its agreement to this subpart. By accepting a benefit 
payment subject to this part, the RDFI authorizes the 
debiting of the Federal Reserve Bank account utilized by 
me RDFI in accordance wim the provisions of §2 10. 10(e). 

(b) The Federal Government. In processing 
reclamations pursuant to this subpart, the Service shall act 
pursuant to the direction of the agency that certified the 
benefit payment(s) being reclaimed. 

§ 210.10 RDFI liability. 

(a) Full liability. An RDFI shall be liable to the 
Federal Government for the total amount of all benefit 
payments received after the death or legal incapacity of a 
recipient or the death of a beneficiary unless the RDFI has 
the right to limit its liability under §2 10. 1 1 of this part. An 
RDFI shall return any benefit payments received after the 
RDFI becomes aware of the death or legal incapacity of 
a recipient or the death of a beneficiary, regardless of the 
manner in which the RDFI discovers such information. If 
the RDFI learns of the death or legal incapacity of a 
recipient or death of a beneficiary from a source other 
man notice from me agency is payments to the 

recipient, the RDFI shall immediately notify the agency of 
the death or incapacity. The proper use of the R15 orR14 
return reason code shall be deemed to constitute such 
notice. 



(b) Notice of reclamation. Upon receipt of a 
notice of reclamation, an RDFI shall provide the 
information required by the notice of reclamation and 
return the amount specifiedin the notice of reclamation in 
a timely manner. 

{^Exception to liability rule: An RDFI shall not 
be liable for post-death benefit payments sent to a 
recipient acting as a representative payee or fiduciary on 
behalf of a beneficiary, if the beneficiary was deceased at 
the time the authorization was executed and the RDFI did 
not have actual or constructive knowledge of the death of 
the beneficiary. 

(d) Time limits. An agency that initiates a request 
for a reclamation must do so within 1 20 calendar days 
after the date that the agency first has actual or 
constructive knowledge of the death or legal incapacity of 
a recipient or me death of a beneficiary. An agency may 
not reclaim any post-death or post-incapacity payment 
made more than six years prior to the date of the notice of 
reclamation; provided, however, that if the account 
balance at the time the RDFI receives the notice of 
reclamation exceeds the total amount of post-death or 
post-incapacity payments made by the agency during such 

six-year period, this limitation shall not apply and the 
RDFI shall be liable for the total amount of all post-death 
or post-incapacity payments made, up to the amount in the 
account at the time the RDFI receives the notice of 
reclamation and has had a reasonable opportunity to act 
on the notice (not to exceed one business day). 

(e) Debit ofRDFFs account If an RDFI does not 
return the full amount of the outstanding total or any other 
amount for which me RDFI is liable under this subpart in 
a timely manner, the Federal Government will collect the 
amount outstanding by instructing the appropriate Federal 
Reserve Bank to debit the account utilized by me 
The Federal Reserve Bank will provide advice of the debit 

totheRDFI. 

[64 FR 17487, Apr. 9, 1999, as amended at 69 FR 1 3 1 89, 
Mar. 19, 2004] 

§ 210.11 Limited liability. 

(a) Right to limit its liability. If an RDFI does not 
have actual or constructive knowledge of the death or 
legal incapacity of a recipient or the death of a beneficiary 
at the time it receives one or more benefit payments on 
behalf of the recipient, the RDFI's liability to the agency 
for those payments shall be limited to: 



(1) An amount equal to: 

(i) The amount in the account at 

the time the RDFI receives 
the notice of reclamation and 
has had a reasonable 
opportunity (not to exceed 
one business day) to act on 
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(ii) 



the notice, plus any additional 
benefit payments made to the 
account by the agency before 
the RDFI responds in full to 
the notice of reclamation, or 

The outstanding total, 
whichever is less; plus 
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(2) 




If the agency is unable to collect the 
entire outstanding total, an additional 
amount equal to: 

(i) The benefit payments 

received by the RDFI from 
the agency within 45 days 
after the death or legal 
incapacity of the recipient or 
death of the beneficiary, or 

(ii) The balance of the 

outstanding total, whichever 
is less. 



(b) Qualification for limited liability. In order to 
limit its liability as provided in this section, an RDFI 
shall: 

(1) Certify that at the time the benefit 
payments were credited to or 
withdrawn from the account, the RDFI 
had no actual or constructive '' 
knowledge of the death or legal 
incapacity of the recipient or death of 

(2) Certify the date the RDFI first had 
actual or constructive knowledge of the 
death or legal incapacity of the 
recipient or death of the beneficiary, 
regardless of how and where such 
information was obtained; 

(3) (i) In cases involving the 

reclamation of Social Security 
Federal Old-Age, Survivors, 
and Disability Insurance 
benefit payments, or benefit 
payments certified by the 
Railroad Retirement Board or 
the Depart 

Affairs, provide the name and 
last known address of the 
following person(s): 

(A) The recipient and 
any co-6wner(s) of 
the recipient's 
account; 



(B) All other person(s) 
authorized to 
withdraw funds from 
the recipient's 
account; and 

(C) All person(s) who 
withdrew funds from 
the recipient's 
account after the 
death or legal 

■ : ■'■■'- 

recipient or death of 
':'■'■'■/■■■■■/ 

(ii) If persons are not identified 

for any of these subcategories, 
the RDFI must certify that no 
such information is available 
and why no such information 
is available; and 

(4) Fully and accurately complete all 

certifications on the notice of 
reclamation and comply with the 
requirements of this part. 

(c) Payment of limited liability amount If the 
RDFI qualifies for limited liability under this subpart, it 
shall immediately return to the Federal Government the 
amount specified in §210.1 1 (a)(1). The agency will then 
attempt to collect the amount of the outstanding total not 
returned by the RDFI. If the agency is unable to collect 
that amount, the Federal Government will instruct the 
appropriate Federal Reserve Bank to debit the account 
utilized by the RDFI at that Federal Reserve Bank for the 
amount specified in §210.1 1(a)(2). 

(d) Violation of subpart ^. An RDFI that fails to 
comply with any provision of this subpart in a timely and 
accurate manner, including but not limited to the 
certification requirements at §210.1 1(b) and the notice 
requirements at §210.13, shall be liable to the Federal 
Government for any loss resulting from its act or 
omission. Any such liability shall be in addition to the 
amount(s) for which the RDFI is liable under §210.10 or 
§210.11, as applicable. 

[64 FR 17487, Apr. 9, 1999, as amended at 69 FR 13 1 89 
Mar. 19, 2004] ' 

§210.12 RDFFs rights of recovery. 

(^Matters between the RDFI audits customer. 
This subpart does not authorize or direct an RDFI to debit 
or otherwise affect the account of a recipient. Nothing in 
this subpart shall be construed to affect the right an RDFI 
has under state law or the RDFI's contract with a recipient 
to recover any amount from the recipient's account. 
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(b) Liability unaffected. The liability of the RDFI 
under this subpart is not affected by actions taken by the 
RDFI to recover any portion of the outstanding total from 
any party. 

§ 210.13 Notice to account owners. 

Provision of notice by RDFI. Upon receipt by an 
RDFI of a notice of reclamation, the RDFI immediately 
shall mail to the last known address of the account 
owner(s) or otherwise provide to the account owner(s) a 
copy of any notice required by the Service to be provided 
to account owners as specified in the Green Book. Proof 
that this notice was sent may be required by the Service. 

§ 210.14 Erroneous death information. 

(a) Notification of error to the agency. If, after 
the RDFI responds fully to the notice of reclamation, the 
RDFI learns that the recipient or beneficiary is not dead or 
legally incapacitated or that the date of death is incorrect, 
the RDFI shall inform the agency that certified the 
underlying payment(s) and directed the Service to reclaim 
the funds in dispute. 

(b) Resolution of dispute. The agency that 
certified the underlying payment(s) and directed the 
Service to reclaim the funds will attempt to resolve the 
dispute with the RDFI in a timely manner. If the agency 
determines that the reclamation was improper, in whole or 
in part, the agency shall notify the RDFI and shall return 
the amount of the improperly reclaimed funds to the 
RDFI. Upon certification by the agency of an improper 
reclamation, the Service may instruct the appropriate 
Federal Reserve Bank to credit the account utilized by the 
RDFI at the Federal Reserve Bank in the amount of the 
improperly reclaimed funds. 



[64 FR 17487, Apr. 9, 1999, as amended at 69 FR 13189, 
Mar.19,2004] 

Appendix A to Part 210— Standard Disclosure for 
Point-of-Purchase Conversion^Posted Notice 

Notice to Customers Presenting Checks 

Conversion of Checks— If you are presenting a 
check to the cashier, your check will be converted into an 
electronic fund transfer. When you hand your completed, 
signed check to the cashier, your check will be copied. 
The account information from your check will be used to 
make an electronic fund transfer from your account in the 
amount of the check. The cashier will void the check and 
return it to you. 

Insufficient Funds— The electronic fundtransfer 
from your account will usually occur within 24 hours, 
which is faster than a check is normally processed. Do not 
present a check to the cashier unless there are sufficient 
funds available in your checking account. If the electronic 
fund transfer cannot be completed because of insufficient 



funds, we may try to make the transfer up to two more 
times'[and we will charge you a one-time fee of $____, 
which we will also collect by electronic fund transfer] . 

Authorization— By reading this notice and 
handing your check to the cashier, you authorize the 
conversion of your check into an electronic fund transfer. 
If the electronic fund transfer cannot be processed for 
technical reasons, you authorize us to process the copy of 
your original check. 

More 7^rwato/2— A pamphlet with more 
information about this process, including inform 
about your rights under Federal law, is available from the 
cashier. [You may also call __ or visit our Internet site at 
for detailed information.] 

Note: This notice must be conspicuous. This means that 
the notice should be printed on a sign that is prominently 
posted at the location where checks are presented to a 
cashier, in such a way that it is clearly visible from several 
feet away to customers waiting to present checks. 

[67 FR 17903, Apr. 11, 2002] 

Appendix B to Part 210— Standard Disclosure for 
Point-of-Purchase Conversion— Brochure or 

Pamphlet 

What is point-ofpurchase check conversion? 
Point-of purchase check conversion is the process of 
converting checks that customers present to cashiers into 
electronic fund transfers. "Electronic fund transfer" is the 
term used to refer to the process in which we 
electronically instruct your financial institution to transfer 
funds from your account to our account, rather than 
processing your check. When you hand a check to the 
cashier, your check is copied and the account information 
from your check is used to make an electronic fund 
transfer from your account. The cashier voids your check 
and returns it to you. By presenting your check at a 
location where a sign notifies you that your check will be 
converted, you authorize the conversion of your check 
into an electronic fund transfer in this manner. 

How quickly will funds be transferred from my 
account? The electronic fund transfer from your account 
will usually occur within 24 hours, which is faster than a 
check is normally processed. Therefore, you should be 
sure that there are sufficient funds available in your 
checking account when you present your check. If the 
electronic fund transfer cannot be completed because 
there are insufficient funds in your account, we may try to 
make the transfer up to two more times [and we will 
impose a one-time fee of $__ against your account, 
which we will also collect by electronic fund transfer]. 

Will the electronic fund transfer appear on my 
account statement? The electronic fund transfer from your 
account will be on the account statement that you receive 
from your financial institution. However, the transfer may 
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be in a different place on your statement than the place 
where your checks normally appear. For example, it may 
appear under "other withdrawals" or u other transactions." 
The electronic fund transfer should be identified on your 
statement as "[insert]." 

What if there is a problem with the electronic 
fund transfer? You should contact your financial 
institution immediately if you believe that the electronic 
fund transfer reported on your account statement was not 
properly authorized or is otherwise incorrect. Consumers 
have protections under a Federal law called the Electronic 
Fund Transfer Act for an unauthorized or incorrect 
electronic fund transfer. 

What if the electronic fund transfer cannot be 
processed? In rare instances, an electronic fund transfer 
cannot be processed for reasons other than insufficient 
funds. In these cases, we will process the copy of your 
original check. Different rights apply to the processing of 
the copy of the check than apply to an electronic fund 
transfer. 

[More detailed information about this process is available 
on our Internet site at _or by calling .] 

Note: This disclosure must be conspicuous. This means 
that it should be printed in reasonably large typeface. If 
this disclosure is combined with other information, it 
should be set off by contrasting color, by surrounding it 
with a box, or by using other means to ensure that it is 
prominently featured. 

[67 FR 17903, Apr. 11,2002] 

Appendix C to Part 210— Standard Disclosure for 
Accounts Receivable Conversion — Notice 

Notice to Customers Making Payment by Check 

If you send us a check, it will be converted into an 
electronic funds transfer (EFT). This means we will copy 
your check and use the account information on it to 
electronically debit your account for the amount of the 
check. The debit from your account will usually occur 
within 24 hours, and will be shown on your regular 
account statement. 

You will not receive your original check back. We will 
destroy your original check, but we will keep the copy of 
it. If the EFT cannot be processed for technical reasons, 
you authorize us to process the copy in place of your 
original check. If the EFT cannot be completed because of 
insufficient funds, we may try to make the transfer up to 
2 times [and we will charge you a one-time fee of $_, 
which we will also collect by EFT]. 

Note: This disclosure must be conspicuous. This means 
that it should be printed in reasonably large typeface. If 
this disclosure is combined with other information, it 
should be set off by contrasting color, by surrounding it 



with a box, or by using other means to ensure that it is 
prominently featured. 

[69 FR 13189, Mar. 19,2004] 

For questions or comments regarding e-CFR editorial 
content, features, or design, email ecfr@nara.gov. 

For questions concerning e-CFR programming and 
delivery issues, email webteam(a).gpo.g ov. 

Last updated: February 18, 2004 
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2005 FEBERALACH PAYMENT SCHEDULE; 



General Information 



Introduction 



Availability 
of Funds 



The 2005 Federal ACH Payment Schedule, issued by the Department of 
the Treasury, Financial Management Service (FMS), provides the dates of 
Federal Government recurring benefit payments. The schedule includes 
dates for "Treasury Disbursed" (i.e., non-military) payments initiated by 
the Office of Personnel Management (OPM), Railroad Retirement Board 
(RRB), Social Security Administration (SSA), and Veterans 
Administration (VA). The Payment Schedule may be used by financial 
institutions to assist in the processing of Federal Government AGH 
payments. 



In accordance with NACHA Operating Rules, consumer payments (i.e., 
Federal salary and travel payments, benefit payments) must be made 
available for withdrawal no later than the opening of business on the 
settlement date (provided the entries are made available to the RDFI by its 
ACH operator no later than 5:00 p.m. on the banking day prior to the 
settlement date.) Corporate payments (i.e., vendor payments, non-benefit 
payments) must be made available for withdrawal on the settlement date. 



Contacts 



Any questions concerning this Payment Schedule should be directed to 
FMS Customer Assistance Staffs: 



Austin, TX................(5 12)342-7300 

Kansas City, MO...........(816)414-2100 

Philadelphia, PA...........(215)516-8015 

San Francisco, CA..........(41 5)817-7300 



Visit the Green Book at www.fms.treas.ROv/Rreenbook for additional 
information regarding Federal government ACH payments. 



Department of the Treasury 

Financial Management Service 
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